Hi,
IMO the current method (HttpHeaders.getAcceptable*() ) works for the
most cases, because the result is ordered as the q-values said.
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.
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
>