Paul Sandoz wrote:
>
> On Mar 31, 2009, at 10:11 AM, Julian Reschke wrote:
>
>> Stephan Koops wrote:
>>> Hi,
>>> -1
>>> If the accept-Encoding allows GZIP, than the JAX-RS runtime could
>>> decide on its own, that it gzip the data. This it could do with all
>>> encodings, that are allowe. So there is no additional annotation
>>> required.
>>> Ot course the runtime must set the content-encoding header, if it
>>> encode the data.
>>> ...
>>
>> Keep in mind that if the runtime handles this, it will also have to
>> worry about Vary, and do rewriting both outgoing *and* incoming ETags
>> (conditional headers!).
>>
>
> Since GZIP is a lossless encoding is it absolutely necessary to rewrite
> the ETags?
>
*GZIP encoding comes at a CPU cost. Does it really make sense to encode
everything if the client says Accept-Encoding: gzip, deflate? This is
why I thought it should be settable by the resource via annotation or
config.
* To Marc's point: I never understood why encoding was a part of the
content negotiation apis of JAX-RS. If there is a special encoding,
JAX-RS has no way of using MessageBodyReaders and the app-developer will
have to do their own stream processing. IMO, there should have been a
ProducesLanguage ConsumesLanguage annotations too.
* To Ryan's point of there being different encodings. Resteasy came up
with a Meta Annotation in the spirit of HttpMethod for encoding.
i.e.
@ContentEncoding("gzip")
public @interface GZIP {}
* To the ETag point. If gzip is a performance boost, isn't generating a
hash of the output yet another CPU performance loss? Meaning, you
shouldn't be hashing the message body for large responses? A guy from
Apple brought this point up in one of my talks at TSSJS.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com