On Tuesday 15 April 2008 10:22, Brett Schwarz wrote: > I saw that you added the capability (to set the flag) in the nszlib module. > Is this the right place for it (i.e. for ADP compression, there was a > separate command)? I'm not sure myself...so that's a legitimate question. I > guess I don't care much, as long as the functionality is there.
I think that is the best place for a few reasons: 1. The core code is in compress.c, which is just a hook so you can plug in different modules (such as nszlib). It exposes an API to register a compression function which nszlib uses. It also exposes the Ns_ConnSetGzipFlag API. All API which start with Ns_ are available to modules, so they can be used outside of the code in nsd/*. 2. The core code in compress.c doesn't have a Tcl API (this is good). 3. The nszlib module has a Tcl API: ns_zlib. 4. Ns_ConnSetGzipFlag should not be called unless you have a compression function registered. 5. Anyone can add a different module to replace or enhance nszlib without any need to change the core code. However, I wonder if the config parameters should be under a module ns_section instead of under the server ns_section? Also note that there is no mapping of content types. tom jackson > > So the question is how to handle static files. One idea is to check if > > compression is enabled, if so, check if a compressed file exists > > (file.ext.gz), use the uncompressed file to figure out the content type, > > and return the compressed file (assuming the client sends the correct > > headers). > > I think this sounds ok. Might want to piggy back off of what Daniel posted > a while back on this: > > http://www.mail-archive.com/aolserver@listserv.aol.com/msg10630.html > > So, I guess what we can do, is at least start out with the route that Jeff > R. proposed, and create a library (filters) to handle compression, using > the new command to expose the Ns_ConnSetGzipFlag function. If problems > arise doing it this way, or if performance is not good, then we can look > into moving into the core? > > So, I guess we'll need a filter to handle the dynamic pages, and then a > separate filter to handle the static pages (similar to Daniels solution). > > How does that sound? > > Thanks, > --brett > > > > > > ___________________________________________________________________________ >_________ Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
