Sergey,
We went back and forth on the q vs. qs on the server side. I ended up suggesting Marek to use qs as that seems to be the convention followed by others. For example, the Apache HTTP server [1].
Also, it makes it slightly easier to write the spec since there is a case where a media type can have both a q (client) and a qs (server) in Section 3.8 (see S mapping).
-- Santiago
[1]
http://httpd.apache.org/docs/2.2/content-negotiation.html
On Sep 8, 2011, at 11:39 AM, Sergey Beryozkin wrote:
> is there any reason why a 'q' parameter can not also be used in @Produces ?
> 'qs' is a convention - but I reckon
>
> @Produces("text/xml;q=0.8")
>
> is equally clear - because @Produces is a server-side annotation.
>
> of course we can keep 'qs'
> but is the following wrong:
>
> @Produces({"text/xml;q=0.8", "text/html;qs=0.8"})
>
> ?
>
>
> Cheers, Sergey
>
> On 08/09/11 14:47, Santiago Pericas-Geertsen wrote:
>>
>> On Sep 8, 2011, at 8:23 AM, Bill Burke wrote:
>>
>>> Client Accept header should always take precedence over any server side qualifiers. Not sure if the algorithm covers that or not.
>>
>> Yes, it does. Step 7 in Section 3.8 [1] sorts media types using q (client) as secondary key and qs (server) as tertiary key.
>>
>> -- Santiago
>>
>> [1] http://java.net/projects/jax-rs-spec/sources/git/content/spec/spec.pdf?rev=8691007a040ed946afe0d6549186376798c73264
>>
>>>
>>> On 9/6/11 12:26 PM, Marek Potociar wrote:
>>>> Hello experts,
>>>> please review the proposal available on our project wiki and send your feedback:
>>>>
>>>> http://java.net/projects/jax-rs-spec/pages/ServerSideConNeg
>>>>
>>>> Thank you,
>>>> Marek
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>
>
> --
> Sergey Beryozkin
>
> http://sberyozkin.blogspot.com
> Talend - http://www.talend.com