Yes, it's actually arelationship between bandwidth, traffic, and
processing power. It makes sense in my case even though I'm low traffic
because my upstream bandwidth (on an ADSL line) is so limited and I have
oodles of cycles to spend on gzip compression.
I don't mind making it controllable by an option, but I'd prefer the
default to be on.
--a.
Allen Gilliland wrote:
On Thu, 2005-11-10 at 14:45, Matt Raible wrote:
Let's rephrase the question:
For the high-traffic Roller sites, are you using your container to
GZip output, or are you using Roller's built-in GZip filters?
why does high-traffic matter?
I'm using the built-in filters, not any that are provided by Apache or
Tomcat. Therefore, I'm -1 on this change.
Can you give a reason? I didn't say we were going to remove the built-in
filters, I simply said that they would be off by default. You wouldn't be
losing any functionality.
Obviously we can leave them enabled by default and let experienced users figure
out that they can disable the built-in compression and use their containers
filters. However, my feeling is just that this type of functionality is not
something that needs to be duplicated at the application level since most
containers already do it.
-- Allen
Matt
On 11/10/05, Allen Gilliland <[EMAIL PROTECTED]> wrote:
would anyone be opposed to disabling the Roller gzip filters for default
installs?
to make it easier to toggle on/off i am thinking we can add a config property like
"compressOutput.enabled" and make some small modifications to the
CompressionFilter to check that property before compressing output. that seems better
than forcing people to modify the web.xml file.
this seems appropriate because most containers these days offer their own
compression capabilities which means it's one more thing that we don't have to
manage ourselves. obviously we can leave what we have in place for those users
who still want it, but just have it disabled by default.
this would be for Roller 2.1
-- Allen
