Hi Paul,
I like the idea of adding a q value the string in the @ProduceMime
annotation as it's a clean addition and doesn't require a significant API
change like a new attribute. The topic of precedence rules gets a bit more
hairy of course :) At first glance, I was about suggest that we could look
at some existing conneg implementations for some ideas, such as Apache
HTTPD.
The details on how Apache handles content negotiation can be found here:
http://httpd.apache.org/docs/2.0/content-negotiation.html
There probably are some ideas we can borrow from their algorithm but it does
seem to have a bias toward static content. With an API like JSR-311 where
you are most likely dealing with dynamic content, things like step 8 might
have to be ignored as content length may need to be determined after the
resource has been serialized to its representation. In this case, that would
obviously be highly inefficient. But if we ignore content length as a factor
much of the Apache content negotiation algorithm could apply. In order to
maintain consistency across JVMs, we'd have to define how the methods are
sorted and not rely on what reflection returns.
But as I look it, it seems to me that we'd probably need different
algorithms to suite different needs (static vs. dynamic). But I guess the
bigger question is, how to provide the hooks for such a process?
Ryan-
On 9/18/07, Paul Sandoz <Paul.Sandoz_at_sun.com > wrote:
>
> Ryan McDonough wrote:
> > I was just scanning the mailing list archive to see what decisions
> > have been made in regards to Content Negotiation such as Language,
> > Encoding, Charset, and potentially assigning a server-side quality
> > value for a given mime type. I know I got involved in this list a bit
> > later than most, but I'm curious to know if any decisions have been
> > made or if this area is still open for debate?
> >
>
> I think it is still open.
>
> Assigning a quality parameter for a Produce/ConsumeMime would enable the
> deterministic selecting of the appropriate HTTP method. Currently for
> Jersey it is based on method the order of methods returned by Java
> reflection, the order of which is arbitrary. So for the following:
>
> @HttpMethod
> @ProduceMime("application/xml") byte[] getXml() { ... }
>
> @HttpMethod
> @ProduceMime("application/json") byte[] getJson() { ... }
>
> The media type "application/xml" takes precedence on the Sun JVM. If we
> could do:
>
> @HttpMethod
> @ProduceMime("application/xml") byte[] getXml() { ... }
>
> @HttpMethod
> @ProduceMime("application/json;q=0.9") byte[] getJson() { ... }
>
> Then it means the media type "application/xml" always takes precedence
> over "application/json" regardless of the method order. Perhaps we
> should also specify precedence rules for inheritance of HTTP methods
> that produce media with the same quality? Or another, easier, way is to
> allow q values > 1
>
>
>
> As for general content negotiation on media, language, encoding and
> charset there many discussions about returning the set of meta-data of
> the resource to the runtime to do processing, but we did not manage to
> come to agreement on how this would work. I was leaning towards a
> general acceptability processor that would work in a similar fashion to
> the precondition evaluator.
>
> Either way we go i think we need to come up with clear and consistent
> examples that cover the common set of HTTP methods and usage (for
> example, using GET and PUT with preconditions) with static/dynamic
> declaration of the meta-data.
>
> Paul.
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> 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