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] AOLserver 4.5.0 on windows not exiting service
Hello all. I've included Titi's suggestion in the current version of the Win32- OpenACS port. So now NSD is a well behaved windows service. Thanks for your help, Maurizio -- 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 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. 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] Active participation
Andrew Piskorski wrote: On Fri, Apr 11, 2008 at 02:11:30PM -0700, Tom Jackson wrote: It is hard to say if these newer languages (C# and MONO) have these features, probably VB and Python don't: task scheduling: ns_schedule_proc, ns_job concurrent collections: nsv arrays, ns_share, static vars (config structure) atomic variables: nsv arrays synchronizers: ns_mutex, ns_cond, etc. Incidentally, those aren't so much language features, they're more features of the AOLserver/Tcl API and environment. "Tcl" didn't have nsv_* or ANY of the cool stuff above until Jim Davidson and crew added them to AOLserver sometime c. the mid 1990's, after all... Jim and crew deserve much credit for the very advanced state of Tcl's threading capabilities, but he was by no means the first or only person doing mt tcl. There were a few different attempts from various people for various reasons. It was just the AOL guys that had the most complete and worked with the core guys at the time for integration. Jeff -- 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.
