On Jun 28, 2007, at 1:46 PM, Jerome Louvel wrote:
>
> It seems that you mix the ability to expose dynamic representation
> metadata
> and the content negotiation algorithm (interpreting the Accept*
> headers).
>
I don't think its really a matter of mixing them, rather the runtime
hands off to the application when there isn't sufficient static
information to make a determination.
> Those are two separate aspects and I don't think that the
> developers need to
> control the second aspect.
>
> For the first one, we should just have annotation ways to expose those
> metadata, and for some rare cases rely on an "EntityProvider" service.
>
I don't think EntityProvider is related to dynamic metadata. You can
associate some static metadata with one (ConsumeMime, ProduceMime)
but by the time an EntityProvider enters the process all of the
conneg will have already taken place.
For "annotation ways to expose those metadata" do you mean something
like an annotated method that would return, say, the list of
available languages ?
Marc.
>
>> -----Message d'origine-----
>> De : Marc.Hadley_at_Sun.COM [mailto:Marc.Hadley_at_Sun.COM]
>> Envoyé : lundi 25 juin 2007 23:31
>> À : dev_at_jsr311.dev.java.net
>> Objet : Re: Issue 1: Adding additional conneg metadata to
>> @Produce/ConsumeXXX
>>
>> 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.
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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.