Hi Ryan,
It could be useful to develop a reusable path serving resource class
that serves up static content:
class PathServingResource {
PathServingResource(String path) { ... }
@HttpMethod
Response get() {
// transform path to local path on file system
// get the set of variants
// build an acceptable response from the variants
// query the response for the selected variant
// If acceptable get the input stream of the variant
// otherwise return the response (406 not acceptable).
}
}
class MyResource {
@UriTemplate(value="files/{path}", limited=false)
PathServingResource getFile(@UriParam("path") String path) {
return new PathServingResource(path);
}
}
IIRC from where we last left the discussions i was proposing some sort
of acceptable response builder.
The acceptable response builder would be primed with sets media,
language, charset, encoding after which the builder will have the
selected variant from which the developer can query if the response is
not acceptable (in either case the Vary header can be set).
I think something like that could implement the Apache Negotiation
Algorithm. It is a good use-case to track.
Paul.
Ryan McDonough wrote:
> 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
> <mailto: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
> <mailto:dev-unsubscribe_at_jsr311.dev.java.net>
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
> <mailto:dev-help_at_jsr311.dev.java.net>
>
>
>
>
> --
> Ryan J. McDonough
> http://www.damnhandy.com
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109