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.
