On Aug 19, 2008, at 5:57 AM, Stephan Koops wrote:
>
> IMO the current method (HttpHeaders.getAcceptable*() ) works for the
> most cases, because the result is ordered as the q-values said.
>
I agree and
> Why do you removed the q-values from the spec? IMO the runtime
> environmet schould internally use them, or at least allow a spec to
> use them.
>
That is what issue 46 is for, we'll revisit support for "quality of
source" after 1.0. What we had wasn't really in line with what Reto
was asking for (and Apache mod_negotiation implements) and was anyway
underspecified. For 1.0 we'll assume all sources have the same quality
- note that we still use any q-values in accept headers as before.
Also you can still specify q (or qs) values in @Produces or @Consumes,
the spec just doesn't use them.
Marc.
> best regards
> Stephan
>
> Marc Hadley schrieb:
>> On Aug 16, 2008, at 5:38 AM, Reto Bachmann-Gmür wrote:
>>> You cannot interpret the q-value in an RFC compliant way, without
>>> knowing about the relative quality of the producers, so
>>> selectBestAudio would have not only to take the accept-headers but
>>> also the available providers:
>>>
>>> public Response get(@Context HttpHeaders h, @Context Providers
>>> providers) {
>>> List<MediaType> ahs = h.getAcceptableMediaTypes();
>>> // application-based behaviour for media type selection
>>> MediaType bestType = selectBestAudio(ahs, providers);
>>> ...
>>> the selectBestAudio would have to get the producers for all
>>> entries in the accept-header retrieve the q-value by getting
>>> parsing the @Produces annotation and select the best one.
>>>> Note that the runtime algorithm of ordering will not get in the
>>>> way in such circumstances and in no way does it appear that
>>>> applications are no longer benefiting from many features
>>>> otherwise provided.
>>> If the runtime supports the q-value semantics to add that low
>>> quality wma producers for devices that do not (decently) support
>>> another format is trivial. Without that support in the runtime the
>>> application has to care about details (via context-injection,
>>> annotation parsing and returning Response instead of Audio) it
>>> otherwise wouldn't.
>>>
>> I think I understand now what you are asking for, it sounds quite
>> similar to the Apache mod_negotiation approach:
>>
>> http://httpd.apache.org/docs/1.3/content-negotiation.html
>>
>> As you may know, we're currently in the final sprint to complete
>> the specification, reference implementation and TCK for 1.0 and
>> unfortunately we don't have time to consider new features at this
>> point. However I've added issue 46[1] to keep track of this and
>> we'll consider including support for "quality of source" in the
>> next release of the spec - for 1.0 all sources will be assumed to
>> have the same quality. I'll also ensure that there's nothing in the
>> 1.0 spec that will make it hard to add that feature later.
>>
>> [1] https://jsr311.dev.java.net/issues/show_bug.cgi?id=46
>>
>> Thanks,
>> Marc.
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.