[EMAIL PROTECTED] wrote:
[...]
>Ryan Bloom responded...
>
>>I have a few problems with this. 1) We have consistantly declined to
>>accept the mod_Gzip from remote communications.
>>
>
>Correct... and for a while the reason was because everyone thought the
>module was using ZLIB and there has been a long standing aversion to
>including ANY version of GNU ZLIB ( or any other GNU stuff ) into the
>Apache tree. We have personal emails from your board members stating
>that to be the case. If that aversion has evaporated then there is a TON of
>GNU based stuff that is now 'eligible' for inclusion in the core
>distribution, right?
>
What is "GNU ZLIB"?
The zlib that I know is independent of GNU and has BSE-style licensing:
http://www.gzip.org/zlib/zlib_license.html
>GNU issues aside... we have consistently been told that the other reason
>mod_gzip would not be included is because of the 'support' issue. Apache
>has a standing rule that no module goes into the distribution unless you
>are absolutely SURE that it will be adequately supported. Makes sense.
>
>We have been consistently supporting this technology for years now.
>Ian himself said he 'Just got bored and decided not to do any real
>work one weekend' and cranked out a filter demo that happened to
>include ZLIB. He has not demonstrated any intention of actually
>'supporting' it other than making a few modifications to the 'demo'
>( and even those have yet to appear ).
>
>If that doesn't raise the issue of 'will it be supported' I don't
>know what would.
>
I think there's a fundamental difference between mod_gz and mod_gzip
in this regard:
If Ian contributes a 450-line mod_gz implementation and decides to never
touch that code again, that's fine. If the code gets enough +1 votes
to be accepted, it's because at least three other developers have
decided that the code is comprehensible enough for others to debug
and maintain it if it breaks.
In contrast, with an 11,000-line implementation like mod_gzip, it's
much less likely that other developers will be able to troubleshoot
the code quickly if it breaks while the original authors are on vacation.
>mod_gzip has NEVER used 'ZLIB' for a number of reasons... the primary
>one being that ZLIB is inadequate for the purpose. ZLIB is a
>non-multithread-safe
>file based compression library.
>
From the README for zlib-1.1.3:
"zlib 1.1.3 is a general purpose data compression library. All the
code is thread safe."
--Brian
