>
>
> ----- Original Message ----
> From: Jeff Rogers <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Sunday, April 13, 2008 3:34:41 PM
> Subject: Re: [AOLSERVER] Compression
>
> 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.
At first I didn't like this idea, but the more I think about it, I'm growing on
it. However, there are some questions still on my mind on whether this is
feasible:
1) How expensive are filters?
2) Not sure if this will work with static pages, altough there might be other
solutions for those...I'll need to dig into this more
3) Will adding this filter interfere with any user/internal filters?
Let me mess around with this approach a little bit, and see how it works out...
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.
