On Aug 15, 2008, at 3:33 AM, Reto Bachmann-Gmür wrote:
> RFC 2616 defines the q-value as indicator of the relative quality,
> not just as mean to sort the request media-ranges. If jax-rs wants
> to fully support this, we must know about the relative quality of
> the representations that can be generated.
>
> The RFC say:
>> The example
>> Accept: audio/*; q=0.2, audio/basic
>> SHOULD be interpreted as "I prefer audio/basic, but send me any
>> audio
>> type if it is the best available after an 80% mark-down in
>> quality."
>
> The server obviously cannot fully satisfy this request, if it
> doesn't know if the audio/basic producer's quality is less than 80%
> inferior than the producer of audio/something-else.
>
An application is free to implement more sophisticated matching rules,
all the information is available. I think the simple approach of just
matching based on the Accept header q-values will be fine for the
majority of cases.
Marc.
>
> Marc Hadley wrote:
> >[...]
>>> Example:
>>> The class Song encapsulates an ogg-vorbis stream, on the server
>>> there are producers for following content-types:
>>>
>>> - application/ogg;q=1
>>> - audio/x-ms-wma;q=.8
>>> - audio/mpeg;q=.9
>>>
>>> As our audio object encapsulates ogg-vorbis data, so application/
>>> ogg can be produced without quality loss, but producing mp3
>>> reduces quality by 10% and wma 20%.
>>>
>>>
>>> The client sends a request with the following header:
>>>
>>> Accept: audio/x-ms-wma, audio/mpeg;q=.9, application/ogg;q=.7
>>>
>> Given the above I think its perfectly acceptable for the framework
>> to automatically select audio/x-ms-wma. An alternative selection
>> can be implemented within an application if desired.
>
> This seems acceptable here, as the quality difference is so small,
> what if on the server audio/x-ms-wma is generated by a very
> experimental producer generating "audio/x-ms-wma;q=.1"? If there are
> clients which support only wma and listening to the Song in poorest
> quality is considered better than nothing, it makes sense to install
> such a producer, but delivering wma to the client described above
> would be clearly against how we should interpret the request
> according to the RFC.
>
> Reto
>
>> Marc.
>>> Delivering audio/mpeg the user can listen to the song with a 19%
>>> mark-down in quality and that's the best quality she can get.
>>>
>>> Reto
>>>
>> ---
>> 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
>
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.