[Mono-dev] State of aspnetwebstack on mono

Sun Nov 2 13:51:03 UTC 2014

I don't really have a strong opinion.   Can you teens me the email you want
me to look at?

On Sunday, November 2, 2014, Martin Thwaites <monoforum at my2cents.co.uk>
wrote:

> Thanks Miguel,
>
> I'll remove that and rebase then.  As the test does both protect an
> unprotect, should there really be a separate test?
>
> Martin
>
> On 2 November 2014 13:09, Miguel de Icaza <miguel at xamarin.com
> <javascript:_e(%7B%7D,'cvml','miguel at xamarin.com');>> wrote:
>
>> Hello Martin,
>>
>> The TODO should be used to flag to the consumer that something is not
>> implemented or half implemented.
>>
>> But we do not do this for missing items that could be configured out of
>> band.  For those, if they matter, we file bug reports.
>>
>> Miguel
>>
>> On Sun, Nov 2, 2014 at 4:20 AM, Martin Thwaites <monoforum at my2cents.co.uk
>> <javascript:_e(%7B%7D,'cvml','monoforum at my2cents.co.uk');>> wrote:
>>
>>> Amazing, thanks Miguel, comments inline.
>>>
>>> On 2 Nov 2014 00:52, "Miguel de Icaza" <miguel at xamarin.com
>>> <javascript:_e(%7B%7D,'cvml','miguel at xamarin.com');>> wrote:
>>> >>
>>> >>
>>> >> PR1349: https://github.com/mono/mono/pull/1349
>>> >> This is the machine key work, and needs a small tweak before it can
>>> be merged that I will do this week.
>>> >
>>> >
>>> > I believe the TODO can be removed.   Can you do that?  See comments on
>>> pull request.
>>>
>>> I don't believe the TODO can be removed as the Encrypt Decrypt methods
>>> don't allow you use custom decryptors (from what I could tell) it's 4.5
>>> specific functionality and controlled via the Web.config.
>>>
>>> Do you want me to expand on the TODO to make it clearer?
>>> >
>>> >>
>>> >> PR1363: https://github.com/mono/mono/pull/1363
>>> >> Another of mine with the MembershipPasswordAttribute
>>> >
>>> >
>>> > Do you mind resending this?  It can no longer be auto-merged from the
>>> UI.
>>>
>>> Before I send this, I need to change the build order in the mcs/class
>>> makefile, and wanted to run that past you first as it strikes me as
>>> something via fragile.  I sent a message to the list a few days about it,
>>> could you respond on that and I'll resend?
>>> >
>>> >>
>>> >> PR1365: https://github.com/mono/mono/pull/1365
>>> >> This is Kornel Pal's around the HttpTaskAsyncHandler, and Miguel has
>>> said he'll take a look at it.
>>> >
>>> >
>>> > Manually aded
>>> >
>>> >>
>>> >> PR1370: https://github.com/mono/mono/pull/1370
>>> >> Small one implementing a default of the ReadEntityBodyMode
>>> >
>>> >
>>> > Got this one by hand.
>>> >
>>> >>
>>> >> PR1371: https://github.com/mono/mono/pull/1371
>>> >> Another small one, implementing the ClientDisconnectedToken
>>> >
>>> >
>>> > And this one automatically.
>>> >
>>> >>
>>> >> PR1372: https://github.com/mono/mono/pull/1372
>>> >> A final small one around the GetBuffer* methods in the httprequest.
>>> >
>>> >
>>> > I do not like this one.  Is there a reason we can not implement the
>>> required functionality instead?
>>> It's not actually required as the default on ReadEntityBodyMode means
>>> that all clients of the code should go directly to input stream.  The code
>>> here is enough to ensure that calling code works.
>>>
>>> Looking at various posts about how to used the
>>> GetBufferlessInputStream,  it looks like it needs Async reads as well as
>>> Synchronous, so it's a little more involved.
>>>
>>> The only thing that we could potentially do is change the exception to
>>> one you get when you try to read it buffered when classic is set.
>>> >
>>> > Miguel
>>> >>
>>> >> There is 1 final small piece that either myself of Chris Carroll will
>>> get done this week which is around the AppendTrailing slash and
>>> lowercaseUrls properties in RouteBase class.  We just need to put the
>>> implementation together.
>>> >>
>>> >> Anyway, after applying all of these, my large WebAPI solution not
>>> only compiles, but it also runs!
>>> >>
>>> >> If you want to checkout what it looks like with all the patches
>>> applied, that would be great, I'd love to have some more information on
>>> whether it does work.  I'm sure there will still be bugs, but if it works
>>> mostly, then bug fixing is easy (famous last words).
>>> >>
>>> >> https://github.com/martinjt/mono/tree/mvc_allfixes
>>> >>
>>> >> Thanks for everyone's help.
>>> >>
>>> >> Martin
>>> >>
>>> >> On 20 October 2014 20:42, Martin Thwaites <monoforum at my2cents.co.uk
>>> <javascript:_e(%7B%7D,'cvml','monoforum at my2cents.co.uk');>> wrote:
>>> >>>
>>> >>> Hi Miguel,
>>> >>>
>>> >>> The code that I'm referring to here is that of the aspnetwebstack on
>>> codeplex.  That is to say that they are not something where you can remove
>>> the code and recompile (unless there as a specific mono implementation
>>> which is not ideal).  The goal is to have the compiled dlls that are
>>> available on nuget work, without tweaking to a person's application.
>>> >>>
>>> >>> I'll have a look and see if I can see where it would be used, but
>>> still as you've said on one of my pulls, a half done implementation is
>>> better than none.
>>> >>>
>>> >>> Having the application throw a missing method exception should not
>>> be the recommended approach when we can add the property and default it to
>>> false.
>>> >>>
>>> >>> Thanks, and please don't think that things won't getting better with
>>> my reviews.  I'm learning what you want so I can review better and help
>>> reduce the burden on you and your staff.
>>> >>>
>>> >>> Martin
>>> >>>
>>> >>> On 20 Oct 2014 20:04, "Miguel de Icaza" <miguel at xamarin.com
>>> <javascript:_e(%7B%7D,'cvml','miguel at xamarin.com');>> wrote:
>>> >>>>>
>>> >>>>> As for the properties, although they should do something to the
>>> generated urls, simply adding them should surely be a valid pull?  the
>>> issue at the moment is that without them, you get an exception even if it
>>> should be false.  I actually think that these are used by other classes
>>> when generating urls, not the route collection itself, but I don't know for
>>> sure.  Considering that adding them is very low risk, can we not just
>>> accept the pull and ask for further work.
>>> >>>>
>>> >>>> Nope, all they do is allow some code to be compiled, and then get
>>> the wrong result.
>>> >>>>
>>> >>>> You might as well remove the dependency of those properties, and
>>> see what else breaks on whatever piece of code you are trying to build.
>>> >>>>
>>> >>>> Miguel
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Mono-devel-list mailing list
>>> >> Mono-devel-list at lists.ximian.com
>>> <javascript:_e(%7B%7D,'cvml','Mono-devel-list at lists.ximian.com');>
>>> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> >>
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141102/89a27fac/attachment.html>