[Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2
grendel at twistedcode.net
Fri Sep 25 05:32:37 EDT 2009
Chuck Esterbrook wrote:
> On Thu, Sep 24, 2009 at 1:20 PM, Marek Habersack
> <grendel at twistedcode.net> wrote:
>>> Nick Berardi wrote:
>>> But by leaving out these stub API's the Mono project is essentially
>>> forbidding any application that references these API's from running on
>>> their software, even if the application fully supports .NET 2.0 pre and
>>> post SP2. (which is when they were introduced) At the very least these
>>> API's should be marked with MonoTODOAttribute and committed so that
>>> applications that want to work around API's not currently implemented in
>>> Mono can do so.
>> Frankly, I don't understand your resistance to implementing the transfer API - what are the
>> technical reasons for not doing it? From MSDN docs it seems it should be pretty simple to implement,
>> why not just do it (I can't do it right now as I'm busy with other things atm) and commit the full
> Marek, if you can't do it now because you're busy with other things,
> then it's easy to imagine that Nick can't do it now because he's also
> busy. Also, Nick probably has less knowledge about ASP.NET internals
> which raises the cost of implementation for him.
This is the obstacle all of us contributing to Mono encountered at some point. I think Nick and I
came to a conclusion regarding the issue. If Nick doesn't have time to implement them, I will - but
not right away and not now. This is an opensource project, created and developed by community -
usually people submit patches in areas they are interested in, and that works best - as everybody
will do their best to implement code as good as they can, because they themselves are going to use
it and they themselves know the context in which they are using it.
> I would think a simple patch that avoids MissingMethodExceptions would
> be a good thing and easy to accept.
On surface, yes, in reality - no. We really try to avoid stubbed methods committed for the sake of
having them but with no functionality. It is very likely that after comitting, the stubs will remain
unimplemented for unknown time, thus providing a false ilussion that Mono supports this or that
API, which will cause (for instance) MOMA reports to show false positives etc. etc. NOT accepting
stubs has also the effect that people (including ourselves in the team) are motivated to actually
implement the code, IMHO.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list