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.
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
>