httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: The issue of mod_aspdotnet
Date Wed, 15 Feb 2006 21:02:24 GMT
On 2/15/06, William A. Rowe, Jr. <> 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

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

View raw message