Re: JSR311: gzip encoding

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 30 Mar 2009 14:24:39 -0400

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 ?


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
> <> 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:
> For additional commands, e-mail:
> --
> Ryan J. McDonough