On Sunday, May 6, 2001, at 04:58 PM, Graham Leggett wrote:
> Chuck Murcko wrote:
>
>> Httpd is getting huge when you count all the support projects it
>> includes. I think we're moving in the wrong direction keeping it as a
>> monolithic release.
>
> I'm thinking in terms of someone who has had to maintain an Apache +
> extra modules before. It may make life easier for us in some ways, but
> it sure sucks for the end user.
>
I have done this as well (and it does suck), and I'm not proposing to
make anything more difficult for the end user. They still get a full
binary or source release that's the same as what they get now in 1.3. We
just call it a rollup release. Nothing changes except how we get from
httpd-2.0 dev code to a rollup release. The only additional output of
the process is a barebones httpd release, before the rollup release.
I mean, if I understand your main complaint, we could solve that with an
actual cvs alias that assembled apr, apr-util, httpd-2.0, and
httpd-proxy/module-2.0 when you check out httpd to test, no? And any
other subprojects that are sufficiently closely tied to the core. That
way everyone works off the same dev code base.
>> My opinion has changed in the opposite way yours
>> has, from thinking mod_proxy needed to be in the core to thinking both
>> it and httpd are better off with a 2 stage release process.
>
> The hassle here is that mod_proxy does belong closer to the core. Both
> the mod_core and the proxy_http modules are both very similar to each
> other, sharing a lot of common code. Ideally Apache should be able to:
>
> - provide frontend modules for connecting browser -> server.
> - provide backend modules for connecting server -> HTTP | filesystem |
> CGI | FTP | Jserv | etc
>
> Obviously this is a development for Apache > 2.0, but moving proxy away
> from the core now is moving in the wrong direction.
Both the core and the proxy are becoming protocol neutral, and we're
talking about trying to make and deliver a project of larger scope than
httpd-1.3 here, if I'm perceiving this whole thread correctly. Splitting
up and parallelizing the development & release seems better for that,
remembering that the output of the whole process (an httpd rollup
release) must deliver the same type of package that a user gets now with
1.3, or better.
Tracking the core just doesn't seem that hard a thing to do to achieve
this.
Chuck Murcko
Topsail Group
http://www.topsail.org/
