Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 46064 invoked by uid 500); 19 Nov 2002 14:40:20 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 46051 invoked from network); 19 Nov 2002 14:40:20 -0000 Message-ID: <3DDA4D82.4030401@apache.org> Date: Tue, 19 Nov 2002 15:41:06 +0100 From: Henri Gomez User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: [PATCH] mod_deflate extensions References: <3DCBEBD6.20302@apache.org> <2147483647.1036752265@[10.0.1.11]> <5.1.0.14.2.20021111133726.027afc50@pop3.rowe-clan.net> <3DD9E286.1080409@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Jeff Trawick wrote: > Henri Gomez 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 ?