>
> I have to agree with Tom. I don't think the application should be
> making decisions about if and when to send data compressed.
> I think it should be handled in the config the same as the character
> encoding is handled.
>
> Tom Jackson wrote:
> > I thought that someone had suggested that the compression feature should be
> > handled without any flags, but based upon configuration parameters and
> > client
> > headers.
> >
> > The main reason for this is because you would have to do the checks anyway,
> > does the compression library exist, can the client accept compression, etc.
> > Then what do you do if compression is requested and it doesn't exist?
> >
> > Maybe this discussion happened over at OpenACS.org, but this is equivalent
> > to
> > an ssl layer, in general the application layer shouldn't get involved in
> > this
> > type of detail.
> >
> > tom jackson
Let me clarify this a little bit. First of all, it would use the existing
scheme for ADP pages. So, this part would not change at all. It would utilize
the existing configuration. Currently, for ADP pages to be compressed, you have
to do these things:
1) turn compression on in ns_section "ns/server/${servername}" as such:
ns_param gzip on
2) Specify the minimum size of the data that will be compressed in the same
section:
ns_param gzipmin 1024
3) In the ADP section ns_section "ns/server/${servername}/adp", turn it on for
ADP
ns_param gzip on
4) In the ADP page, if you want the page to be compressed, you just do:
ns_adp_compress 1
So, what I am proposing is that ns_return follows a similar structure. When I
proposed having a flag (#3 below), I was merely mimicking #4 above. For me
personally, I think I would have compression on all the time (meaning, have the
server decide when to compress). But, I assume since ns_adp_compress command is
in there, perhaps there is some reason why you might not want to compress
certain pages. So, I believe the way it works with ADP pages is (i.e server
logic):
1) it first checks that ns_adp_compress is set.
2) if yes, then if would check if the client supports compress
(Accept-Encoding: gzip...)
3) if yes, it would then check the size, and based on gzipmin, would decide
whether or not to compress the data
Right now, I have in my sandbox just a new command, ns_returnz, which is
exactly like ns_return, but will set the Ns_ConnSetGzipFlag flag internally,
and then the server will do the same decisions as above in 2 and 3. I think
this would be my preferred option, although if someone happens to share some
light on maybe edge cases where you might want to turn it on/off in the script.
*If* we do decide to go with a "flag" (similar to ns_adp_compress), I would
like to see the default to be "on".
So, in summary, the server will be doing most of logic. ns_adp_compress is
there (I presume) to handle edge cases. So, really, I think my question boils
down to whether or not to have a command to set the flag.
I hope that clears things up.
> >
> > On Friday 11 April 2008 08:23, Dave Bauer wrote:
> >
> >> Dossy,
> >>
> >> I think the discussion is just this:
> >>
> >> As Bret clearly stated at the beginning of the thread:
> >>
> >> 1) modify ns_return to take a flag. The optional connid parameter
> >> makes parsing the args a little trickier.
> >> Current:
> >> ns_return ?connid? status type string (is connid ever used??)
> >> New
> >> ns_return ?connid? status type string ?gzip?
> >> OR
> >> ns_return ?connid? status type string ?-gzip boolean?
> >>
> >> 2) add a new command similar to the workarounds:
> >> ns_returnz status type string
> >>
> >> 3) Expose Ns_ConnSetGzipFlag to the script level. This would be most
> >> similar to how the ADP compression is done
> >>
> >> I would like to see it but I don't forsee being able to write the code.
> >>
> >> Dave
>
__________________________________________________
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.
