On Sat, Sep 01, 2001 at 06:19:32PM -0700, Ryan Bloom wrote:
> On Saturday 01 September 2001 14:56, Justin Erenkrantz wrote:
>
> I have a few problems with this. 1) We have consistantly declined to
> accept the mod_Gzip from remote communications.
mod_gzip implements the gzip algorithm. It also happens to be a 300k
source file (~11,000 lines). mod_gz is a 14k file and is 446 lines
and relies on zlib.
Knowing the people on this list I will bet that the size of the file
went a long way for us not accepting Remote Communications's version
in the core distribution. My cause for not accepting mod_gzip would
be that implementing the gzip algorithm is better left to someone
else - like the guy who wrote gzip. I mean no offense to Remote
Communications as I'm sure their implementation is sound.
I will accept the most concise and correct version - at this time,
Ian's version is the only one being offered. (My one complaint
about mod_gz is that it needs to be moved out of Eastern Europe.)
> 2) I keep hearing that
> zlib has more memory leaks than a sieve.
As Cliff has pointed out, if there are memory leaks in zlib, then
this will sniff them out. Both Opera and Mozilla rely on zlib for
handling their gzip Transfer-Encoding. I am sure that their products
would benefit if the Apache Group can fix their memory leaks.
There hasn't been a release of zlib since 1998. I'm not concerned
about this (because if there were memory leaks, *someone* would have
addressed them by now). I'm also not amused by the suggestion that
this "may" be a security hole. This is a read-only operation that
we are performing.
> 3) I don't believe that we
> should be adding every possible module to the core distribution. I
> personally think we should leave the core as minimal as possible, and
> only add more modules if they implement a part of the HTTP spec.
I believe that this does implement a core component of the HTTP spec
- namely Transfer-Encoding. Most current browsers have gzip support
built-in (Netscape, Opera, and Mozilla do - I bet IE does, but I
don't use it) - however, we have never supported this. I believe it
is time that we do so. Not having implemented this is a major
oversight on our part.
> Putting every module into the core is NOT the answer to this problem.
> IMNSHO, Apache should be a minamilistic web server. If we don't need
> it in the core, it shouldn't be there. Personally, I would remove
> mod_dav from the server too, because it doesn't implement part of
> RFC2616.
I believe that DAV belongs in our standard module set because it is
treated as an extension to HTTP. The same goes for our inclusion
with SSL.
I believe that anything that adds value to the server out-of-the-box
belongs in the main repository. Things like mod_pop3 and mod_mbox
are special modules that no one really cares much about. We did them
as proofs of concepts - if they help, cool, but they aren't part of
the officially supported httpd-2.0 code - you don't want to maintain
or enhance mod_pop3 and I don't want to maintain or enhance mod_mbox.
My +1 for adding this to the core distribution of modules stands.
I fully believe that adding this functionality to the server is
completely worth it.
Can I either receive two more +1s or a straight out veto? (AIUI,
a non-veto -1 is treated as a -0. Please correct me if I am wrong.)
-- justin
