httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PATCH] mod_deflate extensions
Date Sun, 24 Nov 2002 17:03:09 GMT

>--On Friday, November 22, 2002 12:03 PM +0100 Henri Gomez
><> wrote:
>> So we should use a copy of mod_gzip compression code in Apache 2.0.
>> Also as someone involved in mod_jk/jk2, I'll need gzip
>> compress/uncompress support in Apache 2.0 for a new ajp protocol
>> I'm working on, so having compression/uncompression in Apache 2.0
>> will be mandatory for me.
> Justin wrote...
> No, we shouldn't be including zlib code (or any variant) in our
> distribution.  That's not our responsibility.  It's also not
> important enough for us to further bloat our code just because an
> insignificant number of distributions haven't provided a good package
> of zlib.  If it's that important, those administrators can build
> their own zlib or just not use any functionality requiring zlib.  The
> point here is that no functionality is lost if zlib is missing.

I guess that's where some would disagree and the point
of Henri's original posting. I happen to think that a LOT
of 'functionality' is 'missing' from Apache if it can't
do compression/decompression 'out of the box' but that's
certainly no secret since I've been voicing that opinion
for some years now. It's still just one man's opinion,
as is yours. Diff strokes for Diff folks.

> (And, if you are doing a mod_jk, zlib support should be optional not
> mandatory.)
>> Ok, let be pragmatic. Did Apache HTTP developpers agree that
>> compression should be added in Apache 2.0 by incorporating mod_gzip
>> comp code in Apache 2.0 ?
> mod_deflate is already there and it uses an external zlib library, so
> I'm confused why we should also provide mod_gzip and/or its
> proprietary compression code.

No one has suggested 'also providing mod_gzip'. That's a
dead issue. Apache will never be using 'mod_gzip'.

The issue was whether or not it's time to think about
adding some actual compression/decompression code (like
ZLIB) to the source tree itself and/or the Non-ZLIB inline
compression engine that mod_gzip uses which is perfectly
do-able and pretty much a no-brainer.

...and for the record... the 'compression code' in mod_gzip
is NOT PROPRIETARY. It is still just simple public domain
LZ77 + Huffman. It is as 'open-source' as your own
product (Apache), if not even more-so. ALL of the code
for mod-gzip ( compression engine(s) included ) has been
donated to Apache 3 different times and it's all still
sitting there on your hard drives ready for you to do
whatever the heck you want with it. All of mod_gzip
is also now sitting up at SOURCEFORGE free as the wind
and under the same 'do whatever you like with this'

> mod_gzip is freely available, and the ASF doesn't need to distribute
> it (Remote Communications evangelizes it enough).

RCI has nothing do with mod_gzip anymore.
mod_gzip is all sitting up on SOURCEFORGE for some time now.

> One of the main
> reasons for selecting mod_deflate was that it didn't unnecessarily
> duplicate code.  Less code is better.   We don't need to repackage
> zlib.  I have no desire for us to compete with the zlib maintainers.
> We have enough work as-is.  -- justin

All points well taken.

Your points go against the advice of people
who actually wrote ZLIB ( Dr. Mark Adler and others )
with regards to anyone who 'distributes' applications
that (may) depend on it (ZLIB) but your concerns about
how much the Apache Group is able to deal with are

Jeff Trawick has already said he thinks including
the 'minimal' amount of code neeeded by Apache
to do what mod_deflate needs to do in the SRC
tree itself would be GOODNESS and would
circumvent a lot of build problems/bug reports but
therein lies the issue itself.

If it comes to a vote I would focus on that one
single issue. Forget about mod_gzip's LZ77 engine
or any other version of LZ77 that 'could' be used...
if the Apache Group isn't even willing to add
a minimal subset of ZLIB code to the SRC tree
and compile/link against it then there's no use
discussing whether that extends to any 'other'
compression/decompresion code as well.


View raw message