Ian Holsman wrote:

> 4. mod_gzip is beter
>         It could be, and it probably does a better job of compression. Once
>         your code is published we'll see. If it is better it will replace 'gz'
>         (if gz gets accepted) my only issue with mod_gzip (1.3 not 2) is it's
>         size, and it's replication of what looks like gzip code inside of it.

Since I don't see that this discussion is going to anywhere, let me suggest
the following, in order to have a progress:

Kevin will publish his code for 2.0, although he prefers to wait for a more
stable release of 2.0.

"In return", nobody will judge it according to its current status, since
Kevin already proved (in the 1.3's release) that he could write a high
quality mod_gzip, so the assumption will be that if it happened with 1.3,
it will happen with 2.0 too, once 2.0 will meet Kevin's standards. In
addition, Kevin has more experience in this field than anybody else.

The "size" problem will be judged simply:

Once the code is published, it will be compiled under a standard platform
(Linux?), and with the default flags (i.e. no "-g" or "-DMOD_GZIP_DEBUG1").

Then, the command "size mod_gzip.o" will be invoked, and its output, which
is based only on the REAL code (without the 90% debugging stuff, comments,
etc.) will be the base for a decision.

I suggest also to take into account that this code contains EVERYTHING (I
believe that zlib alone is bigger than it), so you don't need anything else
or any dependency.

Also, the fact that much of its size is dedicated for meeting the RFC, must
be taken into account. Once another gzip filter meets it, it will become
large too.

I apologize in advance if I offence anybody; I'm just trying to settle the
argument and to make some progress; I believe that finally there is a 
concensus that having a gzipping filter is critical for the success of
Apache. I hope we will not be back with sayings like "let PHP and JSP
compress themselves"; It is not acceptable, and it's like saying "let PHP
and JSP SSLing themselves". Didn't we invite the I/O filtering for these
purposes?

Sorry again,
-- 
Eli Marmor
[EMAIL PROTECTED]
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-23-7338          Kfar-Saba 44641, Israel

Reply via email to