>>> c) Treating mod_proxy maintenance as NOT tied to httpd, mod_proxy
>>> development as running on its own release cycle, mod_proxy code has
>>> its
>>> own cvs module (hey, we can start module-2.1 now, right), and is
>>> released with httpd distribution. Note that this may require some
>>> reintegration at each httpd release (and more work than b).
I agree with this.
>> I think folding it back into httpd development will cause it to
>> "flounder" again.
I agree with this.
> Aha, now we're getting somewhere. I thought that last bit was running
> through the discussion as an undercurrent, but no one was actually
> writing the words down.
Let me throw in a different perspective of things. Apache is cool. It
is big and has many moving parts -- very much like perl (not the
laguage, but the packag{e,ing}).
I maintain a few modules for perl, and so does the next guy and thus we
have the glorious CPAN. Some claim that perl is more-or-less useless
without any of the modules that go with it -- like some people that
claim Apache is useless without mod_proxy (and other modules). Their
individuality dictates their righteousness.
The reason perl "works" is because CPAN rocks. There is no reason that
the configuration process for Apache couldn't just just query
www.apache.org and ask, "What is the latest version of mod_proxy that
works with Apache x.y.z?" And have www.apach.org send back a tarball
and it gets compiled in.
If people had to rerelease their perl modules inline with the perl
distribution, the whole system would fall apart. The CPAN concept lends
itself directly to this problem and could potentially be a integral
building block that allows clean separation of all of the Apache-related
projects while completely unifying them on the distribution front.
Are there any objections to building a distribution system for Apache's
core who's build process relies on dynamic module fetching? Like:
CAMDiN "Comprehensive Apache Module Distribution Network".
It would make distributing mod_backhand a lot easier for me :-). And it
would make mod_proxy _extremely_ accessible while completely untying it
from the apache development cycle.
Thoughts?
--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E 2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
