[Mono-dev] State of aspnetwebstack on mono

[Martin Thwaites]

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> 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>
> wrote:
>
>> Amazing, thanks Miguel, comments inline.
>>
>> On 2 Nov 2014 00:52, "Miguel de Icaza" <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>
>> 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> 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
>> >> 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/318d0c91/attachment-0001.html>