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.