Don Baccus wrote:
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.
Sorry, I didn't mean to stir up a bitter previous discussion, but there
is some similarity in debating where to put a particular piece of
functionality. The point of my suggestion was to say, if its just as
easy then why not have it both ways?
A week or so ago someone wrote a sort of guideline for what kinds of
modifications are good, and those are the ones that generalize the core
and allow the specific needs of some app to be met more easily. I'm
trying to do just that - generalize the core and allow the applications
to do what they need. However, as alot of apps don't want or need to
care about these pieces of functionality, then also include as part of
the app server some small library to make it work as expected (i.e., as
the config file says.) The thing about config file settings as I see it
is that making the core (i.e., c code) vary its behavior based on config
settings is a big hassle, while doing in in tcl is much easier.
So change the core to expose a way to set the compression flag from tcl,
but ignore the config setting in the core. Then include by default some
tcl code that sets the compression flag on every request based on the
config file setting. From the point of view of the 99% of applications
that don't care, the config file setting controls whether compression is
used or not. But for an application that wants to be choosier about it,
the option is there to easily replace the logic for when to set the flag.
-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.
