On 2/15/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> 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 [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. 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 [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.) > * 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 [EMAIL PROTECTED] 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
