From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 25 Jun 2007 17:31:08 -0400

On Jun 25, 2007, at 4:37 PM, Jerome Louvel wrote:
>
> If annotations on Representation POJOs don't make sense (I don't
> remember
> the exact reasons anymore... hence the interest in the Wiki, issue
> tracker),
> then maybe the POJO to Representation conversion service could help
> here.
>
> As a result, the developer wouldn't even need the "isAcceptable"
> mechanism.
>
Right, we already support this for the Accept and Content-Type
headers via the ConsumeMime and ProduceMime annotations on a resource
method or EntityProvider.

There are cases though where there isn't sufficient static
information for an implementation to do all of the content
negotiation even if we restrict ourselves to content type. E.g. a
resource method might return Object so the implementation won't know
until runtime whether a returned object can be converted into a
suitable representation or not. In that case we might want to provide
additional means for a resource class method to query the contents of
the Accept header to see what format the client prefers.

The question really boils down to how far we should go - we already
provide access to the raw header and a means to plug-in a custom
header parser (HeaderProvider) so an application could already write:

@HttpMethod(GET)
Object getSomething(@HeaderParam("Accept") SomeAcceptListAbstraction
accept) {...}

with an associated

@Provider
public class SALAProvider implements
HeaderProvider<SomeAcceptListAbstraction> {...}

Should we define standard type(s) and associated provider(s) for the
Accept, Accept-Language, Accept-Encoding and Accept-Charset headers ?
Should we add some specific helper methods as Paul and I suggested
earlier in the thread ?

I think I could live with a general purpose
"QValuedCommaSeparatedList" type and associated standard provider to
aid in parsing and sorting of the components of an Accept-XXX but at
the moment I'm dubious about going much further.

Marc.

>
>> -----Message d'origine-----
>> De : Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
>> Envoyé : lundi 25 juin 2007 16:05
>> À : dev_at_jsr311.dev.java.net
>> Objet : Re: Issue 1: Adding additional conneg metadata to
>> @Produce/ConsumeXXX
>>
>> Hi Jerome,
>>
>> We already have the Response.(Builder) mechanism to return meta data
>> plus an entity. So I don't see the need to provide such
>> annotations on a
>> Java class that is representation (plus there are issues with this we
>> have discussed at length before).
>>
>> The key bit i see that is missing is how the developer can ascertain
>> what is acceptable and to signal when something is not
>> acceptable. That
>> is what i was proposing via some helper methods.
>>
>> if (x.isAcceptable(..., ..., ...)) {
>> } else if x.isAcceptable(...)) {
>> } else { return null; }
>>
>> The developer could do things dynamically via their own Response
>> implementation or they could use the Response.Builder.
>>
>> Paul.
>>
>>
>> Jerome Louvel wrote:
>>> Hi Paul,
>>>
>>>> Agreed, we can do that now with Produce*. But, the cases i am
>>>> trying to
>>>> highlight are when what is acceptable cannot be determined
>> statically:
>>>>
>>>> 1) a method is declared to produce more than one acceptable
>>>> thing, for
>>>> example "image/*" but only certain image formats are
>> supported, the
>>>> number of which grows over time; and
>>>
>>> In this case, we need a @MediaType annotation on the
>> representation class
>>> itself, indicating the method that exposes the media type
>> dynamically.
>>>
>>>> 2) if we choose not to do non-declarative negotiation on certain
>>>> acceptable information, such as language (i suspect that
>> for language
>>>> the common case is to grow the number of supported languages
>>>> over time
>>>> without changing existing networking every time a new
>>>> language is added).
>>>
>>> The same @Language annotation approach could works equally
>> well for dynamic
>>> scenarios.
>>>
>>> Best regards,
>>> Jerome
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>>
>>
>> --
>> | ? + ? = 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
>>
>
> ---------------------------------------------------------------------
> 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.