On Sat, Sep 01, 2001 at 07:50:19PM -0700, Ryan Bloom wrote:
> On Saturday 01 September 2001 18:53, Cliff Woolley wrote:
> > On Sat, 1 Sep 2001, Ryan Bloom wrote:
>...
> > > 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.
We ship code that uses it. zlib fixes their code (or somebody else fixes
it). Now our module rocks. Chicken and egg... A ton of other projects use
zlib. I see no reason for us to avoid it. If it *does* happen to have leaks,
then (when somebody finds this to be true) they could fix it.
> > > 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.
The gzip content encoding is 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
Agreed!
> > 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.
But it isn't "invisible" if you do it with Perl, PHP, Python, or CGI. A
person has to explicitly code it.
I'm really looking forward to mod_gz(ip) in Apache 2.0 so that Subversion
can transfer its content in compressed form. All of that comes out of a
database... it can't be precompressed, so that leaves a filter to do the job
as it hits the wire. Doing large checkouts are almost *always* network bound
rather than server/client bound. Compressing those files is a *huge* win.
> -1 (vote, not veto), for putting mod_gz in the core.
Please use -0.9 or something. It gets really confusing to see -1 and never
know what it means. As I've said before: -1 really ought to always mean a
veto. But... that's just me :-)
Needless to say, I'm +1 on the concept. It's a big win for everybody. I
haven't reviewed the code yet, so no commentary there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
