A product of the cli-dev incubation effort was the open sourcing of the
mod_aspdotnet connector between httpd-2.0 and Microsoft's ASP.NET engine.
Some background...
It is notably tied to Microsoft as the code uses a C++ IJW (It Just Works)
approach to compiling native and managed code in the same C++ module, using
Microsoft's bindings for the ASP.NET engine, and httpd/apr's headers and
linkage. Note that MS's patent claims revolve around the System.Web.Hosting
environment, and that the claims, from my reading, didn't cover the actual
System.Web.Host / System.Web.Request classes which 'stuff' the request into
ASP.NET and spin back out the reults. MS does claim patents on techologies
that operate within their ASP.NET framework, and which mod_aspdotnet does
not provide, itself. ASP.NET code runs inside MS's Framework.
At the present time, mono, via mod_mono, is a simple http proxy to a backend
mono http server running their implementation of the ASP.NET framework. From
my earlier understanding, it was not implemented using the System.Web.Host
framework in the same way as Microsoft, but tightly coupled between their
http server implementation and the ASP.NET environment, meaning that plugging
in an alternate System.Web.Host provider into System.Web.Hosting isn't viable.
It is notably not distributed in their 'Patent-Safe' distribution for the
Americas and other places that defer to Microsoft's patent claims. [If I'm
wrong, please correct me.]
There are two major changes to be made to mod_aspdotnet. First is to move this
code forward to Visual C++ 2005; the C++ language in a .NET/IJW environment
has evolved, and no longer overloads native C pointer types and managed C object
references. In fact this code is sitting in my local checkout, waiting for me
to figure out how to declare jagged array results as the return value for a C++
managed function member. The driving force for this change is the availability
for free of the Visual C++ 2005 compiler, potentially interesting more people
in compiling the code themselves.
The second major change to be made is driven by the httpd-2.2 proxy framework.
Because all applications are in effect proxied from the front end server, the
fit of mod_proxy_aspdotnet should be self-evident. However, mod_aspdotnet is
designed to be tightly-coupled and run in-process with the server, and migrating
the code from a 'handler' to a 'proxy endpoint' is a pretty obvious move. The
module doesn't change.
A third major change that could be made is integration with mono, this precludes
using MS C++ (using C# plus C code instead), using the pinvoke API which would
be a larger module (doing the same thing). Obviously the mono project already
has the mod_mono module for doing just this, and that connector can continue
to evolve in their code base or here. I have no opinion one way or the other,
and have little interest in that development myself although I would gladly help
facilitate such a contribution and participate in it's review and long term
care. Note that in this case, we should abstract the C# pinvoke code to consume
MS's API, and any tangential issues with compiling it against and running it
under mono is left to the user. [The pinvoke entry points are the same IIUC.]
For the most part, mod_aspdotnet is just 'done'. Most of the authors on the
list are users, and in fact most of the feedback is user-to-user and has worked
very effectively. I believe;
* It's time to move all mod_aspdotnet discussion to [EMAIL PROTECTED]; this is
very low
traffic, and while it's tangential to C language development going on in the
httpd core, the cli-dev subscribers miss important evolutionary ideas going
on in the core, and the [EMAIL PROTECTED] subscribers miss the very
existance of any
mod_aspdotnet activity. mod_mbox traffic is a good example that this would
be successful.
* It's time to move all mod_aspdotnet user discussion to [EMAIL PROTECTED]
Now I've
struggled with this choice, because this would add some small traffic to an
already busy list. However; I don't believe that users of 'a module' should
be stuck trying to solve that module's issue in isolation of how-to-configure
the rest of the server. The cli-users lose by not better understanding the
rest of httpd. I don't see folks unsubscribing from users@ because of 'off
topic' traffic, as it stands there are many 'foolish' questions posed on that
list, and lots of beginner questions that most readers probably don't need
to read, yet they remain subscribed and helped by that list.
* It's time to move mod_aspdotnet into the 'core'. Not as a default installed
module, perhaps not even in the modules/arch/win32/ tree (it would increase
the size of the unix distributions for no gain), but simply consider it where
it lays in svn as part of httpd 'proper'.
* A final release should be shorn from the repository pre-conversion, and
then the code described above to move to VC2005 and mod_proxy_aspdotnet
can occur, and these long-lived release (I expect them to be somewhat
long-lived based on 2.2 ABI rules and .NET versioning rules) can persist
for those who wish to use this one-platform technology.
* If individuals wish to work on the C#/pinvoke flavor, they have a starting
point and champions here to help shepard the code.
Now we could argue this should only happen with three maintainers. In fact
three +1's from PMC members are be required to release the next version. But
given that the code 'just works', I sort of place it in the same category as
mod_netware_ssl; a not-so-complicated (to some ;-) implementation that is done
and just works. If it loses all attention in the future, then we should kill
it altogether, just as we would kill mod_netware_ssl.
So I'm specifically proposing that the cli-dev subproject be relieved of this
module (the cli-dev's project status itself is the topic for my next post.)
In order to even consider this proposal, I need to take a quick poll...
Voulenteers who will continue to watch the progress of mod_aspdotnet
(oversight)?
Voulenteers who will actually test the module from time to time and vote on
it's release quality?
Voulenteers to continue to offer patches and develop this code, either the
C++ flavor or C# flavor?
Comments on this mod_aspdotnet proposal?
Bill
