Jeff Trawick wrote:
Henri Gomez <[EMAIL PROTECTED]> writes:


When you drop the network bandwith by 30 to 70% factor, you make your IT
managers happy since they save money and you make end-users very happy
since they feel you application is faster.

when you drop the web server throughput by x% factor you may make
yourself sad :)
What do you means by dropping the web server throughput by x% factor,
when you compress replies you send them quicker isn't it ?

So adding mod_deflate to the default distribution, under control of
configure which will verify if zlib is available on the system to enable
it, shouldn't hurt.

I wish it were so simple as finding a zlib, but static zlib
distributed with some OSs vs dynamic zlib distributed with others
seems to be the difference between success and failure.


More users will use mod_deflate, more chance to see remaining bugs
discovered and fixed.

I definitely agree that it would be nice to turn on mod_deflate in the
build automagically, I just don't want to do it at the expense of more
problems encountered by users.  I suspect that we would need to ship a
subset of zlib ourselves in order to have a fool-proof build of it.
If you recall mod_gzip included its own copy of zlib compression/expand
functions, and mod_deflate could do the same. May be APR friends could help us by making an APR facade to gzip/zlib (as they do for DBM for example).

Nota that mod_gzip only use zlib system includes to rebuild its own compress code. Do you want me to send code to include zlib code this way in mod_deflate ?






Reply via email to