httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Vote: mod_jk connector in /experimental
Date Thu, 05 Sep 2002 08:22:59 GMT
On Tue, Sep 03, 2002 at 09:51:20AM -0500, Jess M. Holle wrote:
> It would be nicest of all to have builds of each version of the core for 
> each platform -- and pluggable binaries of all the extra modules for 
> each version/platform as well.

Eergh.. this sounds like a maintenance nightmare.

> This could be cranked out by automated 
> scripts as a release criteria/requirement, i.e. it's not a release until 
> everything builds on all platforms with the automated scripts (and 
> ideally passes some basic tests on all of them too).

I can almost guarantee you this will translate to "we will never again have a

There are still several significant official apache distribution modules from
1.3 which do not yet work under the current 2.0 line.  Considering that we're
talking about creating a repository which presumably will be containing not
only all of this stuff but lots of third-party modules with various levels of
maintenance and stability, requiring that they all compile and work before
releasing a new version of httpd is, frankly, insane.

Personally, what I would like to see is something along the following lines:

1.  A core Apache distribution containing a minimal server.  This would contain
the core code and the few modules required to get the basic HTTPD behavior
everybody expects from any server (serve files off a disk, run CGIs, and not
much else).  This would be useful for those wanting a "lean and mean" httpd
server, or for those who want to build everything custom from the module
repository.  It would also make it easy to release core updates in a timely
fashion, as new releases of this package could be made with a minimum of
modules needing to be updated/tested.

2.  An "enhanced" Apache distribution, containing everything from the minimal
distribution, plus a bunch of really commonly used modules.  This would be
equivalent to what generally gets distributed now.  Criteria for what modules
get bundled into this should be based primarily on demand (only modules that
lots of people out in the real world need and use), and of course there would
be a requirement that any included modules must have people willing and able to
actively develop and debug them in a timely fashion, so that if something
breaks, it doesn't seriously slow down the release schedule (without good
reason).  It would be nice if releases of this package corresponded roughly to
releases of the core package, but if a core change was made which required
updating a lot of stuff, the core package could be released first, while work
is still going on on updating all the other modules in this package to work
with the new core before the enhanced package goes out the door.

3.  A repository of all apache modules (including all the ones from the
enhanced distribution, and from everybody else out there in the world) in a
consistent, well-defined form with a modular build system for the core which
you can just drop them into.  Ideally, I would like to be able to download one
of the above two distributions, unpack the source, cd into the source
directory, and then unpack mod_foo.tar.gz and mod_bar.tar.gz (obtained from the
repository), run configure/make, and get a server which includes the foo and
bar modules just as if they'd been part of the initial distribution.  With a
well-defined module distribution file format and a build system which
automagically supported modular-inclusions, this shouldn't be too hard to

I don't think it's worth trying to do a global binary module repository
(officially).  Those responsible for building binary distributions for any
given platform can obtain and build in all the modules from the repository
which make sense and are well enough maintained to be feasable.  Obviously, it
would be good to compile things in such a way that third-party developers could
also distribute their own binary modules, but I think any
repositories/collections for that sort of thing would best be done on an
as-needed, per-platform basis.


View raw message