Marc Hadley wrote:
> 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.
The point is that the matching wouldn't be based on the interpretation
of the q-value following RFC 2616 but simply using it for sorting the
accept-preferences. By not offering full support by the jax-rs runtime,
applications wanting to do so can no longer benefit from many features
otherwise provided by the jax-rs implementation.
Reto
>
> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>