zlib inclusion and mod_gz(ip) recap (was: [PATCH] Add mod_gz to httpd-2.0)

[Greg Stein <gs...@lyra.org>]

On Tue, Sep 04, 2001 at 03:29:04PM -0400, TOKILEY@aol.com wrote:
>...
> Will the Apache group accept the ZLIB source code
> into the distribution tree at this time?...
> 
> [__] Yes
> [__] No

No. The zlib library is popular enough (read: typically installed) that we
will link against it, rather than include it. A Windows installer may bundle
it, though. (yes, zlib *is* available for Windows; Python uses it)

> if ( Yes )
>..
> else
>   {
>     Will Apache accept pre-compiled ZLIB libraries into the
>      source tree ( for any/all platforms )?

Definitely not.

>...
>     if ( Yes )
>...
>     else
>       {
>         1. How can anyone vote on adding Ian's mod_gz to the source tree
>             when the public domain libraries it needs can't be in the source 
> tree?

See above.

>         2. How is anything in Apache that ever needs ZLIB supposed to  
>             compile? Users must always 'go and get' the libs themselves?

$ rpm -i zlib-devel-1.1.3-6.i386.rpm

>...
> ASIDE: You really only need the 'compression' part of it. You
> are a Server, not a client.

True. But it is all pretty irrelevant if we use zlib by reference.

>...
> As for number 3... I am still of the opinion that your perspective
> is wrong... you are playing 'chicken or egg'. I am of the opinion
> that if ZLIB WAS there then in very short order there WOULD 
> be a 'large chunk of Apache code' that uses it. This is ( and I guess
> always has been ) my point.

We haven't need it so far. When we do, then we write some config macros.

>...
> How in the heck tod the REGEX stuff ever make it in?
> Was that some huge 'catch 22' or 'chicken and egg' scenario
> as well when it was being proposed?
> 
> What was the final straw that broke the stalemate over the
> 'regexec' library inclusion(s)?

The regex directives. Regexes are really needed for file pattern handling.
Real world situations usually require some kind of regex matching, so it
went in.

The inclusion of Expat was definitely a chicken/egg thing: the intent was to
make it easier for Apache modules to use XML (given XML's increasing use and
importance; altho it still boggles my mind that we haven't seen mod_soap or
mod_xmlrpc yet... all the blocks are there).

>...
> What's it going to take to find out once and for all if
> ZLIB can be included in the Apache source tree?

It won't go in. No need for it. That hasn't been well-stated, but if you
take a half hour and reread the notes, it kind of surfaces in there. This is
also how we would handle a library like this.

As stated elsewhere, pcre and expat are in there because they aren't
typically available, like zlib is.

> I don't know anymore. I've tried to explain why I think
> it would be a great benefit to Apache to have it there
> ( numerous times going back over a year or more )
> and I have tried to supply as much information as I
> have about the licensing issues ( IANAL ) and I
> have asked for 'real' votes about it... nothing happens...
> just more talk.

Nothing needs to happen, so it shouldn't be surprising :-). If/when we need
it, then we will include it. As I said, it is just config macros.

> Somebody else needs to take this into the end-zone.
> I don't even know where the football is on this one
> anymore.

There are three options on the table:

1) include mod_gzip
2) include mod_gz
3) include neither

I believe there is consensus that (3) is not an option. Despite yours and
Peters pushing and stressing and overbearing "sell job" to get mod_gz(ip)
type functionality into the core, it was just preaching to the choir. (well,
okay: maybe Ryan didn't want to see it in there :-)  That sell job mostly
served to create an air of hostility.

So now the question comes down to using (1) or (2). People are *not* voting
on including mod_gz because they want to see your alternative. I think it is
pretty much that simple.

But then you say to look at the 1.3 version. That is the problem -- people
don't want to see that. They want to see your 2.0 version, which you already
have working in house. Since you've said it exists, they would rather go
that direction, than have to port the 1.3 version up to 2.0. We're all so
busy, that this kind of laziness is excusable :-) Whether the changes are
large or small, they'd rather see your current work because we already know
the port has been completed and *tested*. We'd have to redo all of that
work, which just seems silly.

So the inclusion of either is blocked on seeing the source to mod_gzip for
Apache 2.0.

Now: you state that you don't want to release it until we hit beta. But that
is not how we work, and you should know that by now. We want the module in
there now, *before* beta hits. You say that you don't want to release it
while the APIs are in flux -- that they should be stable. But that is bogus.
If we include mod_gzip *today*, then it will get fixed along with everything
else as we change the APIs. You aren't going to be responsible for keeping
it up to date with the changes. We are. That is part of what going into the
core means -- that we have an obligation and responsibility to maintain it.
And we will. If it goes in.


Summary:

* zlib is not going to be included in any fashion, we'll use it by reference
  if/when we need to

* you should release your 2.0 mod_gzip so that everybody can make an
  informed decision about putting compression functionality into Apache

* if mod_gzip goes in, then it would do so earlier rather than later, and we
  will deal with any API changes that occur between now and ship -- it isn't
  your burden to bear, so there shouldn't be a reason to withold.


Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/