On Mar 30, 2009, at 8:24 PM, Marc Hadley wrote:
> I'm struggling with this one a bit. If the application is doing the
> encoding then we already have facilities with Variant for an
> application to select an encoding that the client understands. The
> only advantage I see with the annotation is that we could then base
> method dispatch decisions on its presence. If the implementation is
> performing the encoding then, like Stephan, I don't really see much
> use for the annotation other than perhaps as an advisory "it would
> be nice if you could encode this" indicator. What am I missing ?
Hmm... yourself and Stephan raise good points and make me think so
more about this.
Jersey supports GZIP encoding as a web-application wide filter based
on the request Accept-Encoding header and the response Content-
Encoding header (if set, which overrides the accept behavior).
I would expect the most common use-case is to enable acceptable
content encoding support for the whole application. Thus it is more
likely to be a property of Application. So i am not sure there are
enough advantages to having a GZIP annotation that explicitly declares
support for only a resource method (or methods if annotated on a
resource class).
Paul.
> Marc.
>
> On Mar 30, 2009, at 1:57 PM, Ryan McDonough wrote:
>
>> That's true Stephan, but my point with the naked @ContentEncoding
>> annotation was to support other, and future encoding types.
>> However, I did not look fully at Bill's implementation in RESTEasy,
>> but he's using meta-annotations whereby the @GZIP is annoated with
>> a @ContentEncoding("gzip") annotation. This follows the same
>> pattern as the JAX-RS @HttpMethod annotations.
>>
>> Ryan-
>>
>> On Mon, Mar 30, 2009 at 1:45 PM, Stephan Koops
>> <Stephan.Koops_at_web.de> 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.
>>
>> best regards
>> Stephan
>>
>> Bill Burke schrieb:
>>
>> It seems to me that most JAX-RS implementations support GZIP
>> encoding. Any way we could require it within the specification?
>> Also maybe define a @GZIP annotation to specify we want to encode
>> the response (of course it would be sensitive to the Accept-
>> Encoding header).
>>
>> In Resteasy we encode the response in GZIP if the content-encoding
>> response header has been set. Our @GZIP annotation sets the
>> content-encoding header.
>>
>> It just seems weird to me that there is no portable way of doing
>> encoding within JAX-RS.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>
>>
>>
>>
>> --
>> Ryan J. McDonough
>> http://www.damnhandy.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>