Paul Sandoz wrote:
>
> Actually i am scratching my head wondering why we specified the q
> parameter for media types on @Produces/_at_Consumes!
>
> It does not seem to add much value since the client decides what it
> wants and in what priority. All it seems to add is "i support Java type
> T for media type X better than you do". Plus when writing your
> reader/writer you have to know that some reader/writer may support Java
> T for media type X better than you do in advance because the maximum and
> default value is 1.0.
Not sure about the best default value, but knowing about quality
differences in producible content is necessary to deliver the optimal
available content. The best format is the one where the product of
server-side and client-side q-value is highest.
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
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