dev@jsr311.java.net

Open questions/issues (was Re: Content Negotiation)

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 18 Sep 2007 11:52:09 -0400

This is issue 1[1] in issue tracker and is still an open question.
I've been remiss in keeping the issues list up to date and I'll try
to rectify that this week. Here's my list of additional open
questions and issues (some broader than others) - what am I missing ?

- Security context: should we add an API whereby an application can
access principle and role information or do we just rely on container-
specific resource injection.
- OutputStream access: should we provide a means for a resource class
to obtain an OutputStream to which a representation can be written or
should we stick with the current approach which requires an entity
provider.
- Breadcrumbs: to help with URI construction it would be useful for a
resource class to be able to access the list of resources whose sub-
resource locators were used to find the resource class.
- Non-annotation model: should we support APIs to allow dynamic
configuration of resource classes not based on annotations - this
would provide an alternative to annotations for platforms where they
are not available (ME, earlier versions of Java, scripting
languages). We'll be adding such an API in the RI, the EG can take a
look at it once its ready and decide if its appropriate for the JSR
or not.
- Resource provider: should we standardize APIs for plugging in
resource class factories or leave it to each implementation to define
its own. We are developing an API in the RI, the EG can take a look
at it once its ready and decide if its appropriate for the JSR or not.
- Relationship to JSR 299 (Web Beans).
- Relationship to JSR 303 (Bean validation).
- Relationship to JSR 314 (JSF 2.0).

Thanks,
Marc.

[1] https://jsr311.dev.java.net/issues/show_bug.cgi?id=1

On Sep 18, 2007, at 5:09 AM, Paul Sandoz 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
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.