You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cli-dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2006/02/15 21:20:48 UTC
The issue of mod_aspdotnet
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 dev@httpd; 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 dev@httpd 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 users@httpd. 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
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> * 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'.
This mirrors, b.t.w., the state of mod_arm4, which isn't a subproject itself,
but an optional module that is part of httpd 'proper'.
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> * 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'.
This mirrors, b.t.w., the state of mod_arm4, which isn't a subproject itself,
but an optional module that is part of httpd 'proper'.
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 2/15/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>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.
>
> How does that compare to what fastcgi / mod_execd would do? It seems
> somewhat similar at first glance.
Similar. The ASP.NET framework runs in-process inside of the httpd worker.
Right now, we hit mod_aspdotnet as a handler; there are a couple concepts to
understand first;
System.Web.Hosting
| This is Microsoft's ASP.NET interface, which we load at startup and
| invoke its methods to register hosted applications from unmanaged C++.
|
\--> Apache.Web.HostFactory
| Proliferates our Hosts into System.Web hosts, from unmanaged
| into .NET managed space.
|
\--> Apache.Web.Host [implements System.Web.Host]
| This object is our view of the ASP.NET Application which speaks
| in the System.Web.Host interface, to set up each and every hosted
| application space. Think similar to an httpd vhost.
|
\--> Apache.Web.WorkerRequest [implements System.Web.SimpleWorkerRequest]
This is the object that we create to pass into System.Web.Hosting
when a new request arrives, and is queried for all the arguments
and environmental aspects of the incoming request.
As a proxy framework module, the big distinction is that we wouldn't preassemble
the request to proxy, but instead we would create our Apache.Web.Request, and it
would interrogate the httpd module as needed to satisfy the ASP.NET engine.
>>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,
>
> Do we have any contacts within mono that we could use to see if their
> developers would be interested in participating in a mod_mono-like
> solution here? If not, then there's no reason to force collaboration.
I bring it up only that if approached, we are receptive, and have no plans to
initiate any sort of action here at this time.
>>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.]
>
> So, the code would work for MS's API and Mono's. But, if there's no
> interest from Mono folks, then it's just pointless busy work.
Bingo, no reason to start the third possible change unless some mono developers
said 'hey! that's how we would rather integrate!' Until and unless that
happened, mod_aspdotnet would be expected to stay pretty quiet. It works.
>>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;
>
> Right - but in order to conduct a release of mod_aspdotnet, we need a
> minimum of three PMC members to sign off on it. How familiar are
> these users with the code base? If there's a bug, can they fix it?
> If so, should these folks be added to the PMC roster?
We will be discovering that very shortly. I intend to offer up a tarball in the
next two weeks of the 'final old flavor' release built in Microsoft Studio .NET
(2002) before moving forward to the new C++.NET language in Studio 2005. There
are some bugs now-fixed, and many users rely on the snapshots over the official
release, which must be addressed up by a proper release.
>> * It's time to move all mod_aspdotnet user discussion to users@httpd. 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.
>
> If we can get buy-in from the current cli-users@ participants to watch
> users@ for mod_aspdotnet help, then I think folding that list as well
> is a good idea. But, we should ask cli-users@ subscribers what they
> think. (I have zero problem shuttering dev-focused lists, but I am
> slightly more hesitant with user-focused lists.)
I agree that this should be put to cli-users@ after dev@httpd and cli-dev@httpd
have offered their feedback, if that's the dev concensus. If it's not the dev
consensus, no reason to bring this up yet to cli-users@ IMHO.
>> * 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'.
>
> Isn't it relatively large? Is it desirable to 'enough' users to have
> this functionality? My hunch is that it wouldn't, so I'd be mostly
> against folding it into trunk. It wouldn't solve the 'can three
> people maintain this code?' core problem.
Large enough that it shouldn't be in the unix/generic distribution. Much like
the single-voulenteer mod_arm4, it applies to a minority of httpd users, so it's
best obtained as a seperate download. In summary, including .rc, .h and .cpp
files, the tree looks like
aspdotnet/
mod/ 33.4kb 891 lines the typical 'apache httpd module' elements
that loads the .NET engine, sets up hosts
and delegates requests (request 'handler')
Apache.Web/ 80.5kb 2136 lines the C++ interfaces that live within .NET
msi_dll/ 9.3kb 317 lines helpers for the installer to find apache
resource/ 16.8kb 3 files images/icons for the installer
aspnet.conf 3.0kb 78 lines the documented example config
README.txt 5.0kb 113 lines comments and status on the module
LICENSE.txt 11.6kb 202 lines you know who to blame on this one :)
LICENSE.rtf 10.9kb 202 lines same file, different presentation
installer.ism
478.9kb 4497 lines The godawful XML file for InstallSheild
that defines how to build the installer
.../*.vcproj|sln
26.5kb 780 lines The VisualStudio .NET 2002 build environ
The majority of LOC's are simply to distribute a binary, and the httpd project
has never raised an issue w.r.t. the httpd core, so I don't expect that to be
an issue w.r.t. an add-in. The 891 lines of traditional 'module' code are
dense and difficult reading, relating to stubbing in .NET managed code through
the COM interface. The 2136 lines of Apache.Web are relatively trivial to read,
being the actual stubs between ASP.NET back into httpd.
>> * 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 you can get 3 +1s. =)
Yup, that's the second test of reviewers.
>> * 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.
>
> I think the real question here is given the code size: are there three
> developers willing to maintain mod_aspdotnet? mod_nw_ssl is 40kb in
> size - it's much smaller and if there's a problem with it and Brad
> leaves (and no one else steps up to maintain it), we probably punt all
> Netware support. My impression is that mod_aspdotnet is a fair bit
> larger.
Your point being? The relationsship to mod_arm4 being considered how?
The origins of mod_python appearing how?
Forgive me if I perceive double standards applied in terms of committers.
I fully agree with the assessment for releases.
> I am willing to see us try the following:
>
> - Immediately fold cli-dev@ into dev@
+1
> - Considering 'promoting' people who have been active around cli
> discussions to PMC
Let's test that. Many folks have piped up here or there; I will search through
the archives (and ask individuals to contact me privately) if they have provided
consistent participation in the project effort, so that I can bring these names
to the attention of the PMC. Several are 'user's users', the sort who haven't
committed code but offered patches and assisted others getting started; the PMC
of httpd has never turned away active user/documentation people and I don't
suppose it would be an issue now.
> The real litmus test is 'Can we release a version of mod_aspdotnet
> following all of our PMC guidelines in the next three months?' If the
> answer proves to be yes, then I'm fine with continuing mod_aspdotnet
> within this PMC. If we don't have three people who feel comfortable
> to +1 a mod_aspdotnet release (and support it accordingly), then we
> should examine another home outside of the ASF for mod_aspdotnet.
I have no intention of leaving ASF httpd for 'greener pastures', my interest
in mod_aspdotnet is not long-term; I would much rather work with httpd in .NET
through the httpd's API, not ASP.NET's API. But obviously there are many users
out there who desire this, and in the framework of the ASF I'm willing to do so.
That doesn't prevent anyone else from creating a fork elsewhere of course, no
matter if httpd continues to support mod_aspdotnet, or drops it.
>>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.)
>
> Development of mod_aspdotnet, at a minimum, must come under control of
> dev@httpd or find another home outside the ASF.
The door's open; it's always been under control of the httpd project (even in
it's incubation it was a sponsored project.) If the httpd PMC provides or had
provided sufficient oversight in the past is a matter of speculation best left
to history. There are no secrets, the process has perpetually been transparent.
>>Voulenteers who will continue to watch the progress of mod_aspdotnet (oversight)?
>
> Given my lack of expertise or Win32 machines, I can't provide much
> help. I've just been tasked to ensure we resolve this issue in a
> timely manner. =)
It seems you have been 'tasked' with the first, no?
Bill
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 2/15/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>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.
>
> How does that compare to what fastcgi / mod_execd would do? It seems
> somewhat similar at first glance.
Similar. The ASP.NET framework runs in-process inside of the httpd worker.
Right now, we hit mod_aspdotnet as a handler; there are a couple concepts to
understand first;
System.Web.Hosting
| This is Microsoft's ASP.NET interface, which we load at startup and
| invoke its methods to register hosted applications from unmanaged C++.
|
\--> Apache.Web.HostFactory
| Proliferates our Hosts into System.Web hosts, from unmanaged
| into .NET managed space.
|
\--> Apache.Web.Host [implements System.Web.Host]
| This object is our view of the ASP.NET Application which speaks
| in the System.Web.Host interface, to set up each and every hosted
| application space. Think similar to an httpd vhost.
|
\--> Apache.Web.WorkerRequest [implements System.Web.SimpleWorkerRequest]
This is the object that we create to pass into System.Web.Hosting
when a new request arrives, and is queried for all the arguments
and environmental aspects of the incoming request.
As a proxy framework module, the big distinction is that we wouldn't preassemble
the request to proxy, but instead we would create our Apache.Web.Request, and it
would interrogate the httpd module as needed to satisfy the ASP.NET engine.
>>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,
>
> Do we have any contacts within mono that we could use to see if their
> developers would be interested in participating in a mod_mono-like
> solution here? If not, then there's no reason to force collaboration.
I bring it up only that if approached, we are receptive, and have no plans to
initiate any sort of action here at this time.
>>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.]
>
> So, the code would work for MS's API and Mono's. But, if there's no
> interest from Mono folks, then it's just pointless busy work.
Bingo, no reason to start the third possible change unless some mono developers
said 'hey! that's how we would rather integrate!' Until and unless that
happened, mod_aspdotnet would be expected to stay pretty quiet. It works.
>>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;
>
> Right - but in order to conduct a release of mod_aspdotnet, we need a
> minimum of three PMC members to sign off on it. How familiar are
> these users with the code base? If there's a bug, can they fix it?
> If so, should these folks be added to the PMC roster?
We will be discovering that very shortly. I intend to offer up a tarball in the
next two weeks of the 'final old flavor' release built in Microsoft Studio .NET
(2002) before moving forward to the new C++.NET language in Studio 2005. There
are some bugs now-fixed, and many users rely on the snapshots over the official
release, which must be addressed up by a proper release.
>> * It's time to move all mod_aspdotnet user discussion to users@httpd. 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.
>
> If we can get buy-in from the current cli-users@ participants to watch
> users@ for mod_aspdotnet help, then I think folding that list as well
> is a good idea. But, we should ask cli-users@ subscribers what they
> think. (I have zero problem shuttering dev-focused lists, but I am
> slightly more hesitant with user-focused lists.)
I agree that this should be put to cli-users@ after dev@httpd and cli-dev@httpd
have offered their feedback, if that's the dev concensus. If it's not the dev
consensus, no reason to bring this up yet to cli-users@ IMHO.
>> * 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'.
>
> Isn't it relatively large? Is it desirable to 'enough' users to have
> this functionality? My hunch is that it wouldn't, so I'd be mostly
> against folding it into trunk. It wouldn't solve the 'can three
> people maintain this code?' core problem.
Large enough that it shouldn't be in the unix/generic distribution. Much like
the single-voulenteer mod_arm4, it applies to a minority of httpd users, so it's
best obtained as a seperate download. In summary, including .rc, .h and .cpp
files, the tree looks like
aspdotnet/
mod/ 33.4kb 891 lines the typical 'apache httpd module' elements
that loads the .NET engine, sets up hosts
and delegates requests (request 'handler')
Apache.Web/ 80.5kb 2136 lines the C++ interfaces that live within .NET
msi_dll/ 9.3kb 317 lines helpers for the installer to find apache
resource/ 16.8kb 3 files images/icons for the installer
aspnet.conf 3.0kb 78 lines the documented example config
README.txt 5.0kb 113 lines comments and status on the module
LICENSE.txt 11.6kb 202 lines you know who to blame on this one :)
LICENSE.rtf 10.9kb 202 lines same file, different presentation
installer.ism
478.9kb 4497 lines The godawful XML file for InstallSheild
that defines how to build the installer
.../*.vcproj|sln
26.5kb 780 lines The VisualStudio .NET 2002 build environ
The majority of LOC's are simply to distribute a binary, and the httpd project
has never raised an issue w.r.t. the httpd core, so I don't expect that to be
an issue w.r.t. an add-in. The 891 lines of traditional 'module' code are
dense and difficult reading, relating to stubbing in .NET managed code through
the COM interface. The 2136 lines of Apache.Web are relatively trivial to read,
being the actual stubs between ASP.NET back into httpd.
>> * 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 you can get 3 +1s. =)
Yup, that's the second test of reviewers.
>> * 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.
>
> I think the real question here is given the code size: are there three
> developers willing to maintain mod_aspdotnet? mod_nw_ssl is 40kb in
> size - it's much smaller and if there's a problem with it and Brad
> leaves (and no one else steps up to maintain it), we probably punt all
> Netware support. My impression is that mod_aspdotnet is a fair bit
> larger.
Your point being? The relationsship to mod_arm4 being considered how?
The origins of mod_python appearing how?
Forgive me if I perceive double standards applied in terms of committers.
I fully agree with the assessment for releases.
> I am willing to see us try the following:
>
> - Immediately fold cli-dev@ into dev@
+1
> - Considering 'promoting' people who have been active around cli
> discussions to PMC
Let's test that. Many folks have piped up here or there; I will search through
the archives (and ask individuals to contact me privately) if they have provided
consistent participation in the project effort, so that I can bring these names
to the attention of the PMC. Several are 'user's users', the sort who haven't
committed code but offered patches and assisted others getting started; the PMC
of httpd has never turned away active user/documentation people and I don't
suppose it would be an issue now.
> The real litmus test is 'Can we release a version of mod_aspdotnet
> following all of our PMC guidelines in the next three months?' If the
> answer proves to be yes, then I'm fine with continuing mod_aspdotnet
> within this PMC. If we don't have three people who feel comfortable
> to +1 a mod_aspdotnet release (and support it accordingly), then we
> should examine another home outside of the ASF for mod_aspdotnet.
I have no intention of leaving ASF httpd for 'greener pastures', my interest
in mod_aspdotnet is not long-term; I would much rather work with httpd in .NET
through the httpd's API, not ASP.NET's API. But obviously there are many users
out there who desire this, and in the framework of the ASF I'm willing to do so.
That doesn't prevent anyone else from creating a fork elsewhere of course, no
matter if httpd continues to support mod_aspdotnet, or drops it.
>>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.)
>
> Development of mod_aspdotnet, at a minimum, must come under control of
> dev@httpd or find another home outside the ASF.
The door's open; it's always been under control of the httpd project (even in
it's incubation it was a sponsored project.) If the httpd PMC provides or had
provided sufficient oversight in the past is a matter of speculation best left
to history. There are no secrets, the process has perpetually been transparent.
>>Voulenteers who will continue to watch the progress of mod_aspdotnet (oversight)?
>
> Given my lack of expertise or Win32 machines, I can't provide much
> help. I've just been tasked to ensure we resolve this issue in a
> timely manner. =)
It seems you have been 'tasked' with the first, no?
Bill
Re: The issue of mod_aspdotnet
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/15/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 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...
Excellent. I've been delegated by the Board to oversee our timely
resolution of this issue.
(I had already started a draft along similar lines, so thanks for
saving me that hassle.)
> 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.
That's a big win all-around for Win32 users and developers. =)
> 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.
How does that compare to what fastcgi / mod_execd would do? It seems
somewhat similar at first glance.
> 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,
Do we have any contacts within mono that we could use to see if their
developers would be interested in participating in a mod_mono-like
solution here? If not, then there's no reason to force collaboration.
> 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.]
So, the code would work for MS's API and Mono's. But, if there's no
interest from Mono folks, then it's just pointless busy work.
> 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;
Right - but in order to conduct a release of mod_aspdotnet, we need a
minimum of three PMC members to sign off on it. How familiar are
these users with the code base? If there's a bug, can they fix it?
If so, should these folks be added to the PMC roster?
> * It's time to move all mod_aspdotnet discussion to dev@httpd; 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 dev@httpd subscribers miss the very existance of any
> mod_aspdotnet activity. mod_mbox traffic is a good example that this would
> be successful.
I think creating multiple mailing lists was a bad idea, so if we
decide to continue with mod_aspdotnet, this is a mandatory minimum
action to take: so +1 to removing cli-dev@ .
> * It's time to move all mod_aspdotnet user discussion to users@httpd. 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.
If we can get buy-in from the current cli-users@ participants to watch
users@ for mod_aspdotnet help, then I think folding that list as well
is a good idea. But, we should ask cli-users@ subscribers what they
think. (I have zero problem shuttering dev-focused lists, but I am
slightly more hesitant with user-focused lists.)
> * 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'.
Isn't it relatively large? Is it desirable to 'enough' users to have
this functionality? My hunch is that it wouldn't, so I'd be mostly
against folding it into trunk. It wouldn't solve the 'can three
people maintain this code?' core problem.
> * 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 you can get 3 +1s. =)
> * 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.
I think the real question here is given the code size: are there three
developers willing to maintain mod_aspdotnet? mod_nw_ssl is 40kb in
size - it's much smaller and if there's a problem with it and Brad
leaves (and no one else steps up to maintain it), we probably punt all
Netware support. My impression is that mod_aspdotnet is a fair bit
larger.
I am willing to see us try the following:
- Immediately fold cli-dev@ into dev@
- Considering 'promoting' people who have been active around cli
discussions to PMC
The real litmus test is 'Can we release a version of mod_aspdotnet
following all of our PMC guidelines in the next three months?' If the
answer proves to be yes, then I'm fine with continuing mod_aspdotnet
within this PMC. If we don't have three people who feel comfortable
to +1 a mod_aspdotnet release (and support it accordingly), then we
should examine another home outside of the ASF for mod_aspdotnet.
> 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.)
Development of mod_aspdotnet, at a minimum, must come under control of
dev@httpd or find another home outside the ASF.
> 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?
Given my lack of expertise or Win32 machines, I can't provide much
help. I've just been tasked to ensure we resolve this issue in a
timely manner. =)
Thanks again for getting the ball rolling. -- justin
Re: The issue of mod_aspdotnet
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/18/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Sorry Justin, tried to ping you last week even in anticipation of this
> question, but you weren't to be found or were ignoring me ;-) I trust this
> syncs with your expectations.
I wasn't ignoring you. However, anything other than email is iffy at
getting in touch with me (I think you were trying to find me on IRC) -
but I've been known not to reply to emails as swiftly as I should as
well. *sigh*
Regardless of any dropped communications, thanks for keeping the ball
afloat. It will either get enough votes - demonstrating oversight -
or it won't. It'll be the truest test we have available. =)
Thanks. -- justin
Re: The issue of mod_aspdotnet
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/18/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Sorry Justin, tried to ping you last week even in anticipation of this
> question, but you weren't to be found or were ignoring me ;-) I trust this
> syncs with your expectations.
I wasn't ignoring you. However, anything other than email is iffy at
getting in touch with me (I think you were trying to find me on IRC) -
but I've been known not to reply to emails as swiftly as I should as
well. *sigh*
Regardless of any dropped communications, thanks for keeping the ball
afloat. It will either get enough votes - demonstrating oversight -
or it won't. It'll be the truest test we have available. =)
Thanks. -- justin
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 3/1/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>I've enjoyed responding to Justin's detailed questions, and appreciate the very
>>few comments which have arrived. That said; I'm closing this survey on March
>>8th, please get any final offers of help above, additional questions or feedback
>>on the proposal composed and addressed on this list by the 8th so that the
>>appropriate disposition of this source code can occur.
>
> The 8th came and wooshed by. ;-) So, what do we think we should do
> now? -- justin
Heh - apr and httpd aught to have released too, which didn't happen (but folks
have worked furiously and debated long to get things right, so that's not any
criticizm, just an observation of what I'm wrapping my head around right now).
I'll roll a candidate that builds against both 2.0 and 2.2, put it to a vote.
There are just a couple folks in cli-dev i've identified as potential pmc
representitives from the effort (based on user@, dev@ and bug tracking
participation) but will hold off for the moment nominating them to hold
such a seat, until we decide if there is enough to sustain aspdotnet here
at httpd. That endorsement would be partly based on continued contribution,
measured by testing/voting on the next/final/abortive attempt to release
win32 mod_aspdotnet.
Incidently, it's also my measure of if I will support / contribute to any
sort of WinHTTP based MPM technology here, or recommend against it for lack
of a Win32 -developer- community. (users@ traffic continues to reflect a
healthy -user- community.)
Until someone has code to share for cli-dev, in terms of a 'native' or natural
.NET layer to pure httpd, I suggest we let that list fold. There was not a
sufficient show of interest to continue that effort as a community. We should
further close the cli-users list and move mod_aspdotnet traffic to users@.
The snapshot/binary will be prepared once I've tagged & rolled httpd-2.0.xx
in the next few days, and it will either be approved, or won't get sufficient
votes, in which case I'll be withdrawing my future efforts in that module.
Thanks to those who've expressed interest in either mod_aspdotnet or some future
.NET framework around and specific to Apache httpd. Expressions of support are
appreciated, but it's time to measure oversight, and the only actual measure of
oversight are PMC members who vote up or down release candidates.
Sorry Justin, tried to ping you last week even in anticipation of this
question, but you weren't to be found or were ignoring me ;-) I trust this
syncs with your expectations.
Bill
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 3/1/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>I've enjoyed responding to Justin's detailed questions, and appreciate the very
>>few comments which have arrived. That said; I'm closing this survey on March
>>8th, please get any final offers of help above, additional questions or feedback
>>on the proposal composed and addressed on this list by the 8th so that the
>>appropriate disposition of this source code can occur.
>
> The 8th came and wooshed by. ;-) So, what do we think we should do
> now? -- justin
Heh - apr and httpd aught to have released too, which didn't happen (but folks
have worked furiously and debated long to get things right, so that's not any
criticizm, just an observation of what I'm wrapping my head around right now).
I'll roll a candidate that builds against both 2.0 and 2.2, put it to a vote.
There are just a couple folks in cli-dev i've identified as potential pmc
representitives from the effort (based on user@, dev@ and bug tracking
participation) but will hold off for the moment nominating them to hold
such a seat, until we decide if there is enough to sustain aspdotnet here
at httpd. That endorsement would be partly based on continued contribution,
measured by testing/voting on the next/final/abortive attempt to release
win32 mod_aspdotnet.
Incidently, it's also my measure of if I will support / contribute to any
sort of WinHTTP based MPM technology here, or recommend against it for lack
of a Win32 -developer- community. (users@ traffic continues to reflect a
healthy -user- community.)
Until someone has code to share for cli-dev, in terms of a 'native' or natural
.NET layer to pure httpd, I suggest we let that list fold. There was not a
sufficient show of interest to continue that effort as a community. We should
further close the cli-users list and move mod_aspdotnet traffic to users@.
The snapshot/binary will be prepared once I've tagged & rolled httpd-2.0.xx
in the next few days, and it will either be approved, or won't get sufficient
votes, in which case I'll be withdrawing my future efforts in that module.
Thanks to those who've expressed interest in either mod_aspdotnet or some future
.NET framework around and specific to Apache httpd. Expressions of support are
appreciated, but it's time to measure oversight, and the only actual measure of
oversight are PMC members who vote up or down release candidates.
Sorry Justin, tried to ping you last week even in anticipation of this
question, but you weren't to be found or were ignoring me ;-) I trust this
syncs with your expectations.
Bill
Re: The issue of mod_aspdotnet
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/1/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> I've enjoyed responding to Justin's detailed questions, and appreciate the very
> few comments which have arrived. That said; I'm closing this survey on March
> 8th, please get any final offers of help above, additional questions or feedback
> on the proposal composed and addressed on this list by the 8th so that the
> appropriate disposition of this source code can occur.
The 8th came and wooshed by. ;-) So, what do we think we should do
now? -- justin
Re: The issue of mod_aspdotnet
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/1/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> I've enjoyed responding to Justin's detailed questions, and appreciate the very
> few comments which have arrived. That said; I'm closing this survey on March
> 8th, please get any final offers of help above, additional questions or feedback
> on the proposal composed and addressed on this list by the 8th so that the
> appropriate disposition of this source code can occur.
The 8th came and wooshed by. ;-) So, what do we think we should do
now? -- justin
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> 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?
Of course I understand that people are busy; httpd has been particularly so with
simply eating our own dogfood at infrastructure.
I've enjoyed responding to Justin's detailed questions, and appreciate the very
few comments which have arrived. That said; I'm closing this survey on March
8th, please get any final offers of help above, additional questions or feedback
on the proposal composed and addressed on this list by the 8th so that the
appropriate disposition of this source code can occur.
Yours,
Bill
Re: The issue of mod_aspdotnet
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> 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?
Of course I understand that people are busy; httpd has been particularly so with
simply eating our own dogfood at infrastructure.
I've enjoyed responding to Justin's detailed questions, and appreciate the very
few comments which have arrived. That said; I'm closing this survey on March
8th, please get any final offers of help above, additional questions or feedback
on the proposal composed and addressed on this list by the 8th so that the
appropriate disposition of this source code can occur.
Yours,
Bill
Re: The issue of mod_aspdotnet
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 2/15/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 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...
Excellent. I've been delegated by the Board to oversee our timely
resolution of this issue.
(I had already started a draft along similar lines, so thanks for
saving me that hassle.)
> 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.
That's a big win all-around for Win32 users and developers. =)
> 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.
How does that compare to what fastcgi / mod_execd would do? It seems
somewhat similar at first glance.
> 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,
Do we have any contacts within mono that we could use to see if their
developers would be interested in participating in a mod_mono-like
solution here? If not, then there's no reason to force collaboration.
> 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.]
So, the code would work for MS's API and Mono's. But, if there's no
interest from Mono folks, then it's just pointless busy work.
> 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;
Right - but in order to conduct a release of mod_aspdotnet, we need a
minimum of three PMC members to sign off on it. How familiar are
these users with the code base? If there's a bug, can they fix it?
If so, should these folks be added to the PMC roster?
> * It's time to move all mod_aspdotnet discussion to dev@httpd; 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 dev@httpd subscribers miss the very existance of any
> mod_aspdotnet activity. mod_mbox traffic is a good example that this would
> be successful.
I think creating multiple mailing lists was a bad idea, so if we
decide to continue with mod_aspdotnet, this is a mandatory minimum
action to take: so +1 to removing cli-dev@ .
> * It's time to move all mod_aspdotnet user discussion to users@httpd. 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.
If we can get buy-in from the current cli-users@ participants to watch
users@ for mod_aspdotnet help, then I think folding that list as well
is a good idea. But, we should ask cli-users@ subscribers what they
think. (I have zero problem shuttering dev-focused lists, but I am
slightly more hesitant with user-focused lists.)
> * 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'.
Isn't it relatively large? Is it desirable to 'enough' users to have
this functionality? My hunch is that it wouldn't, so I'd be mostly
against folding it into trunk. It wouldn't solve the 'can three
people maintain this code?' core problem.
> * 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 you can get 3 +1s. =)
> * 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.
I think the real question here is given the code size: are there three
developers willing to maintain mod_aspdotnet? mod_nw_ssl is 40kb in
size - it's much smaller and if there's a problem with it and Brad
leaves (and no one else steps up to maintain it), we probably punt all
Netware support. My impression is that mod_aspdotnet is a fair bit
larger.
I am willing to see us try the following:
- Immediately fold cli-dev@ into dev@
- Considering 'promoting' people who have been active around cli
discussions to PMC
The real litmus test is 'Can we release a version of mod_aspdotnet
following all of our PMC guidelines in the next three months?' If the
answer proves to be yes, then I'm fine with continuing mod_aspdotnet
within this PMC. If we don't have three people who feel comfortable
to +1 a mod_aspdotnet release (and support it accordingly), then we
should examine another home outside of the ASF for mod_aspdotnet.
> 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.)
Development of mod_aspdotnet, at a minimum, must come under control of
dev@httpd or find another home outside the ASF.
> 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?
Given my lack of expertise or Win32 machines, I can't provide much
help. I've just been tasked to ensure we resolve this issue in a
timely manner. =)
Thanks again for getting the ball rolling. -- justin