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. :)
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
> 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).
> 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.)