On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
> On Sat, 1 Sep 2001, 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.
> That's true, though that was for 1.3.  Just now with Peter's message is
> the first time I've heard that mod_gzip for 2.0 was even nearing release.
> I'm not prejudiced... whichever one is better wins.  :)

Remote Communications has been very vocal about having ported to 2.0
for a very long time.

> I don't suppose the guys at Remote Communications would be willing to
> share the code for mod_gzip for 2.0 with some of us developers privately
> so that we can get a feel for it before it's released publicly, would
> they?

Their code has always been open source.  Their 1.3 code is basically
based on code from Krow at /. 

> > 2)  I keep hearing that zlib has more memory leaks than a sieve.
> Maybe it does, but that can be dealt with.  Even so, it shouldn't be a
> consideration here IMO, at least not yet.  If it really is leaky (which it
> very well might be but we should prove it rather than just going on what
> we heard), then it's a consideration, but it'd be better for somebody to
> just *fix* zlib than for us to throw out both mod_gz and mod_gzip because
> of zlib's deficiencies (assuming we care, which we probably do).

I disagree that this shouldn't be a consideration.  If we are distributing a module
that relies on a library that leaks, then we are suggesting people use a leaking
library.  I would be fine fixing zlib, but if that can't be done, then a memory leak
in zlib would make me a -0.5 very quickly.

> > 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.
> My personal opinion is that this one is important enough that it should go
> in.  Most clients support gzip transfer coding, and it's a very real
> solution to the problem of network bandwidth being the limiting factor on
> many heavily-loaded web servers and on thin-piped clients (read: modem
> users).  mod_gz(ip) could provide a significant throughput improvement in
> those cases, where the CPU is twiddling its thumbs while the network pipe
> is saturated.  This fills a gap in Apache that could be a very big deal to
> our users.  (It's not like it's a big or obtrusive module either, but size
> is not the final consideration in what goes in and what doesn't.)

You know what's really funny?  Every time this has been brought up before,
the Apache core has always said, if you want to have gzip'ed data, then
gzip it when you create the site.  That way, your computer doesn't have to
waste cycles while it is trying hard to serve requests.  I personally stand by
that statement.  If you want to use gzip, then zip your data before putting it 
on-line.  That doesn't help generated pages, but perl can already do gzip, as
can PHP.

-1 (vote, not veto), for putting mod_gz in the core.


Ryan Bloom                              [EMAIL PROTECTED]
Covalent Technologies                   [EMAIL PROTECTED]

Reply via email to