Hi Tom,

Notwithstanding your legitimate issue that gzipping every html and css
file on the fly is counterproductive in many cases, one case this is
not true is serving to mobile devices - if you're on the end of a weak
GPRS connection with a fairly powerful cpu, you are going to notice
the difference between gzipped and ungzipped content.

Just my 2c :)
--
Mark Aufflick
 http://mark.aufflick.com/about/contact
 http://pumptheory.com/about




On Tue, Dec 7, 2010 at 9:51 AM, Tom Jackson <t...@rmadilo.com> wrote:
> On Mon, Dec 6, 2010 at 9:13 AM, Alexey Pechnikov <pechni...@mobigroup.ru> 
> wrote:
>> I'm see the code in connio.c:
>>     /*
>>      * GZIP the content when not streaming if enabled and the content
>>      * length is above the minimum.
>>      */
>>     if (!stream
>>    && (conn->flags & NS_CONN_GZIP)
>>    && (servPtr->opts.flags & SERV_GZIP)
>>    && (len > (int) servPtr->opts.gzipmin)
>>    && (ahdr = Ns_SetIGet(conn->headers, "Accept-Encoding")) != NULL
>>    && strstr(ahdr, "gzip") != NULL
>>    && Ns_Gzip(buf, len, servPtr->opts.gziplevel, &gzip) == NS_OK) {
>> buf = gzip.string;
>> len = gzip.length;
>> Ns_ConnCondSetHeaders(conn, "Content-Encoding", "gzip");
>>     }
>> There are no checks for content-type and older version of Internet Explorer
>> (IE5, IE6 and may be IE7 have a lot of problems with gzipped scripts and
>> styles).
>
> And yet your examples provided even less customization. There is
> almost no reason to waste cpu on compressing output, just provide a
> gzipped file for very large files. Who are you trying to save money
> for anyway?
>
>> I don't think that this code is useful for production.
>
> Right, then don't use it.
>
>> And we may
>> add ETAG functionality and smart caching checksums of results for decreasing
>> data transfer and server loading. I dont know about your situation but my
>> clients have limited internet connections (especially on mobile devices) and
>> ETAG header transmitting is faster when gzipped content...
>
> Then the least of your problems is gzipping content, you need to
> actively minimize the data transfered. But all of this sounds like
> _your_ problem, not the problem of a generic application server. You
> haven't even figured out how automatic compression works in AOLserver
> yet you want to propose additional features.
>
>> For static files
>> on group of hosts application-defined ETAG is helpful too but internal AOL
>> last-modified-since mechanizm is niot useful (it's not the AOL problem, of
>> cource).
>
> ??
>
>> P.S. I dont understand why my suggestion to complete AOL documentation by
>> examples was produce the holywar about Tcl 8.4 vs 8.5 vs 8.6.
>
> Because I'm a jerk and overreact to what I think are idiotic statements?
>
> BTW, you didn't provide any useful additions to AOLserver documentation.
>
>> I think AOL
>> 4.5.1 + Tcl 8.5 is better choice for new projects and Tcl 8.6 is better for
>> some utilities (fast internal base64 realization, half-closed sockets and
>> other features help me to build faster applications with a few lines of
>> code).
>
> I agree with Gustaf: the latest 8.5 is worth the effort. There are
> certain features which simplify very annoying code. This is true even
> if your version of 8.5 is slower than 8.4. But you have to actively
> update your code to take advantage of the new features. The more code
> you have, the less benefit you get from upgrading without code
> conversion. However, Gustaf mentioned a higher stability in 8.5. This
> could easily override the limited benefit of simply moving the Tcl
> library to 8.5 from 8.4.
>
>> Tcl 8.6 documentation of zlib functions is much better than AOL
>> documentation of ns_zlib module and some of this docs and examples can be
>> helpful for AOL, why not?
>
> If you use Tcl, use the Tcl documentation. If you use AOLserver, use
> the AOLserver documentation. I'm not sure why you keep confusing these
> two things.
>
> tom jackson (AKA the jerk)
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
> <lists...@listserv.aol.com> with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
> field of your email blank.
>


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to