Justin Erenkrantz wrote:
On 2/15/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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 [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.
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 [EMAIL PROTECTED] and
[EMAIL PROTECTED]
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
[EMAIL PROTECTED] 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
