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. (And, if you are doing a mod_jk, zlib support should be optional not mandatory.)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.
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.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_gzip is freely available, and the ASF doesn't need to distribute it (Remote Communications evangelizes it enough). 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
