Re: [AOLSERVER] Compression
On Tuesday 15 April 2008 18:22, Tom Jackson wrote: I'll try to combine Daniel's code with my filter to turn on the switch for ns_return. I have a test release of the nszlib module, which handles ADP compression, and static files (taken from Daniel's example filters), plus dynamic data returned via ns_return. There is also an example configuration section: http://rmadilo.com/files/nszlib/ Feedback needed! I also discovered a strange feature that I don't think is documented anywhere. Server modules are added like this: ns_section ns/server/server1/modules ns_param mymodule /path/to/bin/mymodule.so # Tcl module (in server1/modules/tcl/mytclmodule) ns_param mytclmodule tcl With nszlib, there is now both a shared and Tcl module, However if the Tcl module is in server1/modules/tcl/nszlib, you only need one entry to cover both: ns_section ns/server/server1/modules ns_param nszlib /path/to/bin/nszlib.so AOLserver automatically looks in the private tcl directory for nszlib! tom jackson -- 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.
Re: [AOLSERVER] Compression
I don't know where it's documented, but that's been the behavior for a long time; we've relied on it since 3.4.2, and I think Alex Hisen showed me it working in 2.0. I wanted to remember reading it in the Tcl modules section or the server startup section of the old 3.0 manual that's still @ tcl.tk.org, but a reread doesn't find it. Reconstructing the history of our use of the pattern suggests we never did see it documented. I think I'll go try to find a wiki page to update :-) It's super handy when you want to have a very simple C API that can leave most of its argument parsing, integrity checking, or even its complete data initialization to a set of Tcl wrappers. It's the same design pattern (though it uses init.tcl and doesn't package its own tcl library to do it) that's allowed nsperm to remain somewhat usable all these years. In fact, we took our original use of the pattern from nsperm, and it took us another year or so to discover we didn't have to package things quite so badly (i.e., by putting all the tcl files that supported a C API directly in the modules/tcl directory). -- ReC -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf Of Tom Jackson Sent: Wednesday, April 16, 2008 9:57 AM To: AOLSERVER@LISTSERV.AOL.COM Subject: Re: [AOLSERVER] Compression On Tuesday 15 April 2008 18:22, Tom Jackson wrote: I'll try to combine Daniel's code with my filter to turn on the switch for ns_return. I have a test release of the nszlib module, which handles ADP compression, and static files (taken from Daniel's example filters), plus dynamic data returned via ns_return. There is also an example configuration section: http://rmadilo.com/files/nszlib/ Feedback needed! I also discovered a strange feature that I don't think is documented anywhere. Server modules are added like this: ns_section ns/server/server1/modules ns_param mymodule /path/to/bin/mymodule.so # Tcl module (in server1/modules/tcl/mytclmodule) ns_param mytclmodule tcl With nszlib, there is now both a shared and Tcl module, However if the Tcl module is in server1/modules/tcl/nszlib, you only need one entry to cover both: ns_section ns/server/server1/modules ns_param nszlib /path/to/bin/nszlib.so AOLserver automatically looks in the private tcl directory for nszlib! tom jackson -- 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.
Re: [AOLSERVER] Compression
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.
Re: [AOLSERVER] Compression
Don Baccus wrote: On Apr 12, 2008, at 8:46 AM, Brett Schwarz wrote: For *my* application, I would have the config params do the decision almost all of the time. However, I concede that other people's use cases may be different...so I think a hook into the compression decision making from application code is a good idea. I believe what I proposed covers the bases...although the details would need to be worked out... I agree with this, too. Tying in with a different thread, my suggestion for an improvement would be to ship AOLserver should with (or alongside) a standard/sample library that is intended to be looked at and tweaked (the standard library that ships currently is boilerplate). This standard library could include a filter proc to call 'ns_conn gzip 1' (or however it is exposed at the tcl level) based on the config file setting. Another thing to include in this standard library could be compatibility code for the old thread configuration directives mapping them onto the new 4.5 thread configuration commands. -J -- 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.
Re: [AOLSERVER] Compression
On Apr 13, 2008, at 1:48 AM, 'Jesus' Jeff Rogers wrote: Tying in with a different thread, my suggestion for an improvement would be to ship AOLserver should with (or alongside) a standard/ sample library that is intended to be looked at and tweaked (the standard library that ships currently is boilerplate). This standard library could include a filter proc to call 'ns_conn gzip 1' (or however it is exposed at the tcl level) based on the config file setting. Just do it right in the first place. The config file approach would solve 99% of the need, and for those needing explicit control an explicit call to ns_return_compress or whatever would give it to them. Whatever happened to the KISS principle? One of the things I love about AOLserver is its relative simplicity. People always seem to want to screw with that for some reason. Another thing to include in this standard library could be compatibility code for the old thread configuration directives mapping them onto the new 4.5 thread configuration commands. Or just put back the config parameters as they were, they worked fine for everyone for a decade. I don't remember the masses shouting that the config approach wasn't sufficient. It suddenly appeared without discussion nor documentation. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- 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.
Re: [AOLSERVER] Compression
On 2008.04.13, Don Baccus [EMAIL PROTECTED] wrote: Or just put back the config parameters as they were, they worked fine for everyone for a decade. I don't remember the masses shouting that the config approach wasn't sufficient. It suddenly appeared without discussion nor documentation. Uh, either your memory is poor or you need to review the mailing list archives again. The number of times people have asked can I change [a particular setting] without requiring a nsd restart and have been given the answer no, config changes require a server restart has indirectly suggested that if we can move something out of the config and into the runtime environment, it would be preferred as people ask for it repeatedly over time. Being able to tweak and tune thread pools at runtime has come up many, many times. Each time, the answer is: change the config setting and restart, which usually wasn't desirable because restarts during the day on a production system weren't something folks could do ad-hoc, as they were running a single server, not load-balanced ... Seriously, this has been a long-standing ask, to make more config settings modifiable at runtime. Perhaps the way compression has been implemented wasn't perfect, but it was a start, and I think Jeff's suggestion of shipping a filter proc that enables compression server-wide by default is the right answer. Making the setting purely config-driven is just perpetuating the sorry, config settings need restarts problem. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Compression
On Apr 13, 2008, at 5:14 AM, Dossy Shiobara wrote: Uh, either your memory is poor or you need to review the mailing list archives again. Just did, and apparently the search functionality on the archives has a poor memory, too. Seriously, this has been a long-standing ask, to make more config settings modifiable at runtime. Seriously, I've been on this list and part of the community for about a decade, and, no, there have been very few such requests. Can you point to even one such request this year, for instance? Perhaps the way compression has been implemented wasn't perfect, but it was a start, and I think Jeff's suggestion of shipping a filter proc that enables compression server-wide by default is the right answer. Making the setting purely config-driven is just perpetuating the sorry, config settings need restarts problem. People who want can use an explicit call to ns_returnz or whatever one wants to call it. Make the 99% case work easily. Don't be different than apache just because you want to be different. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- 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.
Re: [AOLSERVER] Compression
Is anyone volunteering to do this work (provided there is agreement)? If not, this entire discussion is pointless. Jade On Sun, Apr 13, 2008 at 5:14 AM, Dossy Shiobara [EMAIL PROTECTED] wrote: On 2008.04.13, Don Baccus [EMAIL PROTECTED] wrote: Or just put back the config parameters as they were, they worked fine for everyone for a decade. I don't remember the masses shouting that the config approach wasn't sufficient. It suddenly appeared without discussion nor documentation. Uh, either your memory is poor or you need to review the mailing list archives again. The number of times people have asked can I change [a particular setting] without requiring a nsd restart and have been given the answer no, config changes require a server restart has indirectly suggested that if we can move something out of the config and into the runtime environment, it would be preferred as people ask for it repeatedly over time. Being able to tweak and tune thread pools at runtime has come up many, many times. Each time, the answer is: change the config setting and restart, which usually wasn't desirable because restarts during the day on a production system weren't something folks could do ad-hoc, as they were running a single server, not load-balanced ... Seriously, this has been a long-standing ask, to make more config settings modifiable at runtime. Perhaps the way compression has been implemented wasn't perfect, but it was a start, and I think Jeff's suggestion of shipping a filter proc that enables compression server-wide by default is the right answer. Making the setting purely config-driven is just perpetuating the sorry, config settings need restarts problem. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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. -- Jade Rubick Acting Chief Technology Officer United eWay [EMAIL PROTECTED] tel (503)285-4963 fax (707)671-1333 www.UNITEDeWAY.org -- 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.
Re: [AOLSERVER] Compression
I'll take a stab at it. I already have part of it changed in my sandbox. This has escalated further than my original email, so I'll have to take a look again, but I'm willing to try. I'll probably need some help on some things, but I most likely will be able to do most of the work... - Original Message From: Dossy Shiobara [EMAIL PROTECTED] To: AOLSERVER@LISTSERV.AOL.COM Sent: Sunday, April 13, 2008 9:46:51 AM Subject: Re: [AOLSERVER] Compression On 2008.04.13, Jade Rubick [EMAIL PROTECTED] wrote: Is anyone volunteering to do this work (provided there is agreement)? If not, this entire discussion is pointless. This is why I asked this in a previous message: Eventually, we will settle on a list of things that we've eventually arrived at through this consensus-forming process. At that point, Don (or Tom), how do we go about actually accomplishing these tasks and completing these changes? Do we have any workable way of solving that problem? As you point out, until this problem is solved, all this discussion is pointless. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 21:40, Dossy Shiobara wrote: On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): I just want to remind folks that Apache's design is config-driven by necessity, not by intentional design. In the Apache world, server-based modules are _only_ actionable at configuration time. When you implement gzip compression in PHP, for example, I believe PHP handles all the compression itself--it doesn't communicate back to mod_deflate to handle it. In AOLserver, we DO have the benefit of being able to interact with the server from application code. This allows us to design and implement things better than in Apache, where everything has to be done at config. time or entirely within the application code. I do hope folks keep this difference in mind when trying to design the implementation for AOLserver. I hope it will result in a better solution than what's currently available in Apache. The problem is that if you bind your application to the transport details you have really lost the war, even if you win the battle. Some call this being clever by half. If folks keep anything in mind it should be that applications should not deal with I/O performance details, at least in AOLserver. AOLserver is an application server, which means that it serves the application, the application doesn't serve anything. But this bs is just concerning ns_return. Remember that ns_return is part of the super-fast, HTTP engine. AOLserver does have lower level API which allow application developers to do anything they want. And this level of control is much more than you get with Apache. In general the Apache API is very intrusive and makes too many assumptions on I/O. Compression has always been viewed as a filter function. This concept is complicated in HTTP because you have headers which indicate both the length of the content and the format of the content. But with HTTP, compression is also a conditional feature, which is a problem for an application which tries to specify per-request compression. For one, applications would have to agree on what to do if compression wasn't possible, or a client didn't agree to compression. It isn't an easy concept, and it shouldn't be handled by modifications to the ns_return API. tom jackson -- 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.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 9:40 PM, Dossy Shiobara wrote: On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): I just want to remind folks that Apache's design is config-driven by necessity, not by intentional design. So? It's still the right thing to do in this case. I agree with Brett's proposal. In AOLserver, we DO have the benefit of being able to interact with the server from application code. This allows us to design and implement things better than in Apache Or worse. I hope it will result in a better solution than what's currently available in Apache. I think you meant to say different ... and simply being different is no reason to reject a perfectly good solution to the problem. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- 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.
Re: [AOLSERVER] Compression
On 2008.04.11, Tom Jackson [EMAIL PROTECTED] wrote: If folks keep anything in mind it should be that applications should not deal with I/O performance details, at least in AOLserver. AOLserver is an application server, which means that it serves the application, the application doesn't serve anything. This is why compression was implemented the way it is for ADPs. The application should hint to the server when compression might be appropriate for a response. But, the server is ultimately responsible for determining if compression can happen, doing the compression and handling the I/O. It isn't an easy concept, and it shouldn't be handled by modifications to the ns_return API. Which is why I suggested ns_return_compress, similar to ns_adp_compress but for ns_return'ed responses. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 21:02, Brett Schwarz wrote: The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): http://httpd.apache.org/docs/2.0/mod/mod_deflate.html Amoung other things, you can specify the mime type and browser type to decide on compression as well. http://developer.yahoo.com/performance/rules.html Great links, there was one other thing which I wanted to ask, concerning SSL. Does anyone know if the SSL module does compression before encryption, and if so, how this might impact the decision to compress? tom jackson -- 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.
Re: [AOLSERVER] Compression
I think I would agree with you, if I change your wording slightly: The application should [have the ability to] hint to the server when compression might be appropriate for a response. I think in most scenarios, the config params should be good enough for deciding on when to compress, however, having the ability to add a decision point in the application code I think is worthwhile, and gives the developer a lot of flexibility. For *my* application, I would have the config params do the decision almost all of the time. However, I concede that other people's use cases may be different...so I think a hook into the compression decision making from application code is a good idea. I believe what I proposed covers the bases...although the details would need to be worked out... - Original Message From: Dossy Shiobara [EMAIL PROTECTED] To: AOLSERVER@LISTSERV.AOL.COM Sent: Saturday, April 12, 2008 6:55:53 AM Subject: Re: [AOLSERVER] Compression On 2008.04.11, Tom Jackson [EMAIL PROTECTED] wrote: If folks keep anything in mind it should be that applications should not deal with I/O performance details, at least in AOLserver. AOLserver is an application server, which means that it serves the application, the application doesn't serve anything. This is why compression was implemented the way it is for ADPs. The application should hint to the server when compression might be appropriate for a response. But, the server is ultimately responsible for determining if compression can happen, doing the compression and handling the I/O. It isn't an easy concept, and it shouldn't be handled by modifications to the ns_return API. Which is why I suggested ns_return_compress, similar to ns_adp_compress but for ns_return'ed responses. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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.
Re: [AOLSERVER] Compression
Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- 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.
Re: [AOLSERVER] Compression
I thought that someone had suggested that the compression feature should be handled without any flags, but based upon configuration parameters and client headers. The main reason for this is because you would have to do the checks anyway, does the compression library exist, can the client accept compression, etc. Then what do you do if compression is requested and it doesn't exist? Maybe this discussion happened over at OpenACS.org, but this is equivalent to an ssl layer, in general the application layer shouldn't get involved in this type of detail. tom jackson On Friday 11 April 2008 08:23, Dave Bauer wrote: Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- 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.
Re: [AOLSERVER] Compression
I have to agree with Tom. I don't think the application should be making decisions about if and when to send data compressed. I think it should be handled in the config the same as the character encoding is handled. Tom Jackson wrote: I thought that someone had suggested that the compression feature should be handled without any flags, but based upon configuration parameters and client headers. The main reason for this is because you would have to do the checks anyway, does the compression library exist, can the client accept compression, etc. Then what do you do if compression is requested and it doesn't exist? Maybe this discussion happened over at OpenACS.org, but this is equivalent to an ssl layer, in general the application layer shouldn't get involved in this type of detail. tom jackson On Friday 11 April 2008 08:23, Dave Bauer wrote: Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- 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. -- 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. begin:vcard fn:Jay J. Rohr n:Rohr;Jay email;internet:[EMAIL PROTECTED] x-mozilla-html:TRUE version:2.1 end:vcard
Re: [AOLSERVER] Compression
Hey Dave, Which option would you prefer though? Thanks, --brett - Original Message From: Dave Bauer [EMAIL PROTECTED] To: AOLSERVER@LISTSERV.AOL.COM Sent: Friday, April 11, 2008 8:23:56 AM Subject: Re: [AOLSERVER] Compression Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- 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. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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.
Re: [AOLSERVER] Compression
I have to agree with Tom. I don't think the application should be
making decisions about if and when to send data compressed.
I think it should be handled in the config the same as the character
encoding is handled.
Tom Jackson wrote:
I thought that someone had suggested that the compression feature should be
handled without any flags, but based upon configuration parameters and
client
headers.
The main reason for this is because you would have to do the checks anyway,
does the compression library exist, can the client accept compression, etc.
Then what do you do if compression is requested and it doesn't exist?
Maybe this discussion happened over at OpenACS.org, but this is equivalent
to
an ssl layer, in general the application layer shouldn't get involved in
this
type of detail.
tom jackson
Let me clarify this a little bit. First of all, it would use the existing
scheme for ADP pages. So, this part would not change at all. It would utilize
the existing configuration. Currently, for ADP pages to be compressed, you have
to do these things:
1) turn compression on in ns_section ns/server/${servername} as such:
ns_param gzipon
2) Specify the minimum size of the data that will be compressed in the same
section:
ns_param gzipmin 1024
3) In the ADP section ns_section ns/server/${servername}/adp, turn it on for
ADP
ns_param gzipon
4) In the ADP page, if you want the page to be compressed, you just do:
ns_adp_compress 1
So, what I am proposing is that ns_return follows a similar structure. When I
proposed having a flag (#3 below), I was merely mimicking #4 above. For me
personally, I think I would have compression on all the time (meaning, have the
server decide when to compress). But, I assume since ns_adp_compress command is
in there, perhaps there is some reason why you might not want to compress
certain pages. So, I believe the way it works with ADP pages is (i.e server
logic):
1) it first checks that ns_adp_compress is set.
2) if yes, then if would check if the client supports compress
(Accept-Encoding: gzip...)
3) if yes, it would then check the size, and based on gzipmin, would decide
whether or not to compress the data
Right now, I have in my sandbox just a new command, ns_returnz, which is
exactly like ns_return, but will set the Ns_ConnSetGzipFlag flag internally,
and then the server will do the same decisions as above in 2 and 3. I think
this would be my preferred option, although if someone happens to share some
light on maybe edge cases where you might want to turn it on/off in the script.
*If* we do decide to go with a flag (similar to ns_adp_compress), I would
like to see the default to be on.
So, in summary, the server will be doing most of logic. ns_adp_compress is
there (I presume) to handle edge cases. So, really, I think my question boils
down to whether or not to have a command to set the flag.
I hope that clears things up.
On Friday 11 April 2008 08:23, Dave Bauer wrote:
Dossy,
I think the discussion is just this:
As Bret clearly stated at the beginning of the thread:
1) modify ns_return to take a flag. The optional connid parameter
makes parsing the args a little trickier.
Current:
ns_return ?connid? status type string (is connid ever used??)
New
ns_return ?connid? status type string ?gzip?
OR
ns_return ?connid? status type string ?-gzip boolean?
2) add a new command similar to the workarounds:
ns_returnz status type string
3) Expose Ns_ConnSetGzipFlag to the script level. This would be most
similar to how the ADP compression is done
I would like to see it but I don't forsee being able to write the code.
Dave
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
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.
Re: [AOLSERVER] Compression
I agree with Tom. Would be great to have this option. ~ Alex. On Fri, Apr 11, 2008 at 12:01 PM, Tom Jackson [EMAIL PROTECTED] wrote: I thought that someone had suggested that the compression feature should be handled without any flags, but based upon configuration parameters and client headers. The main reason for this is because you would have to do the checks anyway, does the compression library exist, can the client accept compression, etc. Then what do you do if compression is requested and it doesn't exist? Maybe this discussion happened over at OpenACS.org, but this is equivalent to an ssl layer, in general the application layer shouldn't get involved in this type of detail. tom jackson On Friday 11 April 2008 08:23, Dave Bauer wrote: Dossy, I think the discussion is just this: As Bret clearly stated at the beginning of the thread: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done I would like to see it but I don't forsee being able to write the code. Dave -- 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. -- 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.
Re: [AOLSERVER] Compression
On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: So, what I am proposing is that ns_return follows a similar structure. I'll suggest the introduction of ns_return_compress ?on|off? -- similar to ns_adp_compress, but for ns_return. It would set the Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP context. *If* we do decide to go with a flag (similar to ns_adp_compress), I would like to see the default to be on. In reality, compression of the output stream doesn't make sense until we implement better server-side caching, which I briefly discussed with Jim several years ago. The basic idea is: some requests are mostly static ... generated in response to a dynamic request, but the response across separate requests is static until some event invalidates that cached response. In that scenario, compression of the response makes sense: you compress it once and return the compressed version many times. However, current AOLserver implementation where all dynamic requests are generated dynamically, compression almost doesn't make sense: how many folks are still serving content to narrowband (dialup) users? For the high-bandwidth users, the cost (in time spent) of compressing the response vs. the savings in transmission time is almost equal (thus the minsize parameter, preventing small responses from even being compressed at all). This can partially be addressed in current AOLserver by writing a request handler that checks an NSV cache. On cache misses, the response is generated, compressed and stored in the NSV cache and returned to the client. On cache hits, it's simply an NSV fetch from cache and return the already compressed response. Some things to think about ... -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Compression
On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: So, what I am proposing is that ns_return follows a similar structure. I'll suggest the introduction of ns_return_compress ?on|off? -- similar to ns_adp_compress, but for ns_return. It would set the Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP context. *If* we do decide to go with a flag (similar to ns_adp_compress), I would like to see the default to be on. In reality, compression of the output stream doesn't make sense until we implement better server-side caching, which I briefly discussed with Jim several years ago. The basic idea is: some requests are mostly static ... generated in response to a dynamic request, but the response across separate requests is static until some event invalidates that cached response. In that scenario, compression of the response makes sense: you compress it once and return the compressed version many times. I agree that smarter caching will definitely improve things. However, I think it depends on the use case for the web app. For example, my web app is an internal tool...and there are small number of users, hence not many request/sec. However, I am doing DB queries heavily with big payloads and my server is sitting in a remote office with a small pipe to the main office. So, in my case, gzipping definitely makes sense. I did some subjective tests, and for my case, compression seems to help. I have also been reading this book High Performance Web Sites, by Steve Souders (good book BTW), and he advocates compression. He's an engineer at Yahoo, and they did some detailed studies on this. Here is a cheat sheet for those who are interested: http://developer.yahoo.com/performance/rules.html However, current AOLserver implementation where all dynamic requests are generated dynamically, compression almost doesn't make sense: how many folks are still serving content to narrowband (dialup) users? For the high-bandwidth users, the cost (in time spent) of compressing the response vs. the savings in transmission time is almost equal (thus the minsize parameter, preventing small responses from even being compressed at all). IMHO, I think the cost vs response time savings will lessen more in the future, so the benefits of compression will become more so. This can partially be addressed in current AOLserver by writing a request handler that checks an NSV cache. On cache misses, the response is generated, compressed and stored in the NSV cache and returned to the client. On cache hits, it's simply an NSV fetch from cache and return the already compressed response. It would be great if the core server would handle this ;) Thanks, --brett __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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.
Re: [AOLSERVER] Compression
Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. At the very least, ns_returnz could be a wrapper for what ns_return would do after figuring out the config/compression engine, etc. But it is very unlikely that changing the ns_return API would be a good idea. You can also use a trie to hold a filter type list mapping file patterns and compression functions. The code for picking a threadpool should be easy to reuse for this. In fact, you might be able to add a new config param to the threadpool to enable compression, but the two groups might not overlap enough to help. tom jackson On Friday 11 April 2008 14:40, Brett Schwarz wrote: On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: So, what I am proposing is that ns_return follows a similar structure. I'll suggest the introduction of ns_return_compress ?on|off? -- similar to ns_adp_compress, but for ns_return. It would set the Ns_ConnSetGzipFlag accordingly, but in requests that are not in an ADP context. *If* we do decide to go with a flag (similar to ns_adp_compress), I would like to see the default to be on. In reality, compression of the output stream doesn't make sense until we implement better server-side caching, which I briefly discussed with Jim several years ago. The basic idea is: some requests are mostly static ... generated in response to a dynamic request, but the response across separate requests is static until some event invalidates that cached response. In that scenario, compression of the response makes sense: you compress it once and return the compressed version many times. I agree that smarter caching will definitely improve things. However, I think it depends on the use case for the web app. For example, my web app is an internal tool...and there are small number of users, hence not many request/sec. However, I am doing DB queries heavily with big payloads and my server is sitting in a remote office with a small pipe to the main office. So, in my case, gzipping definitely makes sense. I did some subjective tests, and for my case, compression seems to help. I have also been reading this book High Performance Web Sites, by Steve Souders (good book BTW), and he advocates compression. He's an engineer at Yahoo, and they did some detailed studies on this. Here is a cheat sheet for those who are interested: http://developer.yahoo.com/performance/rules.html However, current AOLserver implementation where all dynamic requests are generated dynamically, compression almost doesn't make sense: how many folks are still serving content to narrowband (dialup) users? For the high-bandwidth users, the cost (in time spent) of compressing the response vs. the savings in transmission time is almost equal (thus the minsize parameter, preventing small responses from even being compressed at all). IMHO, I think the cost vs response time savings will lessen more in the future, so the benefits of compression will become more so. This can partially be addressed in current AOLserver by writing a request handler that checks an NSV cache. On cache misses, the response is generated, compressed and stored in the NSV cache and returned to the client. On cache hits, it's simply an NSV fetch from cache and return the already compressed response. It would be great if the core server would handle this ;) Thanks, --brett __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- 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.
Re: [AOLSERVER] Compression
On 2008.04.11, Don Baccus [EMAIL PROTECTED] wrote: On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. Configuration parameters is too coarse-grained control. Ultimately, the compression flag should be conditionally turned on in a registered filter if you want it at a higher level than in the actual request processing code, itself. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) My two cents, anyhow. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 16:25, Don Baccus wrote: On Apr 11, 2008, at 4:06 PM, Tom Jackson wrote: Regardless of whether this gets integrated with ns_return, or as a config, it is much better to start out with a new API, such as the ns_returnz or ns_return_compress. I would much rather have this be controlled by configuration parameters. We want to be able to write code for distribution using ns_return, and allow those who deploy it to control whether gzip compression is used or not when they configure their service. I agree, I'll stop confusing the issue. Please see my previous comments. tom jackson -- 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.
Re: [AOLSERVER] Compression
On Apr 11, 2008, at 4:41 PM, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. You could allow control by mime-type and size, though I'd say all but the shortest text/* files would benefit. And the Yahoo best practices page referenced earlier suggests that ALL text/* files will benefit, on average. Computers are actually quite fast these days, and while dial-up connections are becoming increasingly rare, the fact is that there are bandwidth bottlenecks that slow the pace at which bits are transmitted from your server to the user's browser. You could also have an explicit ns_returnz for those who want finer- grained control - leave compression off in your configuration file and explicitly request it if you want it. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) This is more micromanaging of delivery that's really required, IMO. Mostly you just want to make sure that only text/* or other uncompressed formats are compressed. Don Baccus http://donb.photo.net http://birdnotes.net http://openacs.org -- 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.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 16:41, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. Ultimately, the compression flag should be conditionally turned on in a registered filter if you want it at a higher level than in the actual request processing code, itself. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) My two cents, anyhow. If configuration is done using a trie, like threadpools, you will have very good control. I think the main point is that ns_return is not the place to decide this, it leads to very brittle code. Also, if I remember correctly, the ns_zlib module can be configured to only compress data which is larger than some minimum number of bytes. So even with a broad compression filter, you should be able to add parameters. For instance, look at Content-Length header, if than some amount, compress and rewrite the header and add others. tom jackson -- 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.
Re: [AOLSERVER] Compression
On Friday 11 April 2008 17:00, Don Baccus wrote: You could also have an explicit ns_returnz for those who want finer- grained control - leave compression off in your configuration file and explicitly request it if you want it. Ug! Yes, this is more or less the basis of my suggestion: a separate API which would bypass the configuration setup. I think it is a dumb idea in general to use it, but it is much better than changing the ns_return API. My original suggestion to use something like ns_returnz was for testing and/or hacking. The configuration part of this code could be more difficult to get right than a simple new command. Like I said in a previous note, you could use a url pattern as a switch, but the idea of using the mime type is probably even better. In addition, it is very likely that this information will be available at the correct time, and the compression operation will always require modification of the headers, so mime type triggers seem very good. tom jackson -- 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.
Re: [AOLSERVER] Compression
- Original Message From: Tom Jackson [EMAIL PROTECTED] To: AOLSERVER@LISTSERV.AOL.COM Sent: Friday, April 11, 2008 5:14:24 PM Subject: Re: [AOLSERVER] Compression On Friday 11 April 2008 16:41, Dossy Shiobara wrote: Configuration parameters is too coarse-grained control. Ultimately, the compression flag should be conditionally turned on in a registered filter if you want it at a higher level than in the actual request processing code, itself. (IMHO, the decision to compress a request should be handled on a per-request basis, as not all requests unilaterally benefit from server-side compression ... so this should be an _intelligent_ decision that's being made by the developer whether to compress the result or not.) My two cents, anyhow. If configuration is done using a trie, like threadpools, you will have very good control. I think the main point is that ns_return is not the place to decide this, it leads to very brittle code. Also, if I remember correctly, the ns_zlib module can be configured to only compress data which is larger than some minimum number of bytes. So even with a broad compression filter, you should be able to add parameters. For instance, look at Content-Length header, if than some amount, compress and rewrite the header and add others. Yes, see my earlier post...there is the gzipmin param that controls the minimum length to compress. The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): http://httpd.apache.org/docs/2.0/mod/mod_deflate.html Amoung other things, you can specify the mime type and browser type to decide on compression as well. Ultimately, here is what I would like to see: 1) config param to enable compression (this is already there) 2) config param to set the minimum size (this is already there) 3) config param for file/mime type to compress. Note that this would take care of the *.adp and *tcl pages as well. 4) Have a command (ns_compress) that could override gzip setting per request/page Or, have a separate command (ns_returnz) that does the over riding. Logic would be: 1) check if compression is enabled globally (#1 above) 2) check file type/mime type to see if compression is enabled 3) check content length to see if gzipmin 4) Override the above if ns_compress is set I think this gives a good control over what you end up compressing. If you are in a high bandwidth, high requests/sec, you might turn off compression, or have gzipmin at a high level. If you are at the other end of the spectrum (me), you will most likely be compressing most things. BTW, one thing I left out in an earlier post. For those interested in the Yahoo performance tips, and for those that use Firefox...there's an extension called YSlow that you can add that will test a web page's response against the 10 performance tips I referred to earlier. It's actually very useful. Thanks, --brett __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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.
Re: [AOLSERVER] Compression
On 2008.04.11, Brett Schwarz [EMAIL PROTECTED] wrote: The Apache folks no doubt have already gone through this analysis/debate. Here is what they have (for Apache 2.0): I just want to remind folks that Apache's design is config-driven by necessity, not by intentional design. In the Apache world, server-based modules are _only_ actionable at configuration time. When you implement gzip compression in PHP, for example, I believe PHP handles all the compression itself--it doesn't communicate back to mod_deflate to handle it. In AOLserver, we DO have the benefit of being able to interact with the server from application code. This allows us to design and implement things better than in Apache, where everything has to be done at config. time or entirely within the application code. I do hope folks keep this difference in mind when trying to design the implementation for AOLserver. I hope it will result in a better solution than what's currently available in Apache. -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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] Compression
So, from my reading, its seems as though that in 4.5, we got on the fly ADP page compression. However, it seems as though there isn't comparable functionality for Tcl files (i.e. ns_return). I know there are some work arounds, but I was just curious why this was not implemented in the core? I took a look at the sources, and it looks fairly straight forward to add this functionality. I see there are three possibilities: 1) modify ns_return to take a flag. The optional connid parameter makes parsing the args a little trickier. Current: ns_return ?connid? status type string (is connid ever used??) New ns_return ?connid? status type string ?gzip? OR ns_return ?connid? status type string ?-gzip boolean? 2) add a new command similar to the workarounds: ns_returnz status type string 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most similar to how the ADP compression is done Or, am I missing something here? Is there already a way to do this (without workarounds)? Thanks, --brett p.s. I'd really like on the fly compression for static files as well (yes, I know there are work arounds). You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com -- 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.
Re: [AOLSERVER] Compression
On Apr 8, 2008, at 1:54 PM, Brett Schwarz wrote:
So, from my reading, its seems as though that in 4.5, we got on the
fly ADP page compression. However, it seems as though there isn't
comparable functionality for Tcl files (i.e. ns_return). I know
there are some work arounds, but I was just curious why this was
not implemented in the core? I took a look at the sources, and it
looks fairly straight forward to add this functionality. I see
there are three possibilities:
1) modify ns_return to take a flag. The optional connid parameter
makes parsing the args a little trickier.
Current:
ns_return ?connid? status type string (is connid ever used??)
I use:
ns_return_gzipped $conn $x
which is this, and works very reliably:
proc ns_return_gzipped {conn html} {
if {[string first {gzip} [ns_set get [ns_conn headers] {Accept-
Encoding}]] == -1} {
ns_return $conn 200 text/html $html
return TCL_OK
}
# john 9/21/07 -- found that we need to convert to utf-8, it isn't
automatic
set zl [ns_zlib gzip [encoding convertto utf-8 $html]]
set h [subst {HTTP/1.0 200 OK
MIME-Version: 1.0
Server: MoochServer/4.5.0a
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: [string length $zl]
Content-Encoding: gzip
$zl}]
ns_write $conn $h
return TCL_OK
}
--
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.
Re: [AOLSERVER] Compression
Hey John,
I use something similar...in fact I think I stole it from an older post from
you, IIRC. However, I guess my point was, that the mechanism is all there in
4.5. The *only* thing that is needed for ns_return's to return compressed data
is to set a flag (via Ns_ConnSetGzipFlag)...that's it. It's seems like a shame
to me to let that go to waste...
Thanks,
--brett
- Original Message
From: John Buckman [EMAIL PROTECTED]
To: AOLSERVER@LISTSERV.AOL.COM
Sent: Tuesday, April 8, 2008 2:59:44 PM
Subject: Re: [AOLSERVER] Compression
On Apr 8, 2008, at 1:54 PM, Brett Schwarz wrote:
So, from my reading, its seems as though that in 4.5, we got on the
fly ADP page compression. However, it seems as though there isn't
comparable functionality for Tcl files (i.e. ns_return). I know
there are some work arounds, but I was just curious why this was
not implemented in the core? I took a look at the sources, and it
looks fairly straight forward to add this functionality. I see
there are three possibilities:
1) modify ns_return to take a flag. The optional connid parameter
makes parsing the args a little trickier.
Current:
ns_return ?connid? status type string (is connid ever used??)
I use:
ns_return_gzipped $conn $x
which is this, and works very reliably:
proc ns_return_gzipped {conn html} {
if {[string first {gzip} [ns_set get [ns_conn headers] {Accept-
Encoding}]] == -1} {
ns_return $conn 200 text/html $html
return TCL_OK
}
# john 9/21/07 -- found that we need to convert to utf-8, it isn't
automatic
set zl [ns_zlib gzip [encoding convertto utf-8 $html]]
set h [subst {HTTP/1.0 200 OK
MIME-Version: 1.0
Server: MoochServer/4.5.0a
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: [string length $zl]
Content-Encoding: gzip
$zl}]
ns_write $conn $h
return TCL_OK
}
--
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.
You rock. That's why Blockbuster's offering you one month of Blockbuster Total
Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
--
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.
