>--On Friday, November 22, 2002 12:03 PM +0100 Henri Gomez ><[EMAIL PROTECTED]> 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' conditions. > 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 well-grounded. 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. Yours... Kevin
