users@jsr311.java.net

Re: q-value support (was Re: MediaType.isComaptible)

From: Reto Bachmann-Gmür <reto_at_gmuer.ch>
Date: Wed, 20 Aug 2008 20:22:54 +0200

Marc Hadley wrote:
> On Aug 19, 2008, at 11:16 AM, Reto Bachmann-Gmür wrote:
>
>> Marc Hadley wrote:
>>> For 1.0 we fix the q (or qs) value for methods and providers to 1.0
>>> so the product is always the same as that specified in the Accept.
>> As the q-value is syntactically just an argument to the media-type
>> it's hard to forbid it. Would something like the following do?
>>
>> "This specification does not define how server-side q-values are
>> handled, the algorithms described in this specification assume a
>> q-value of 1.0 for methods and providers,
>
> I'm in agreement this far.
>
>> implementations MAY use server side q-values to select the best
>> available contents, if they to do the interpretation of the Accept
>> header SHOULD conform to the interpretation provided by RFC 2616".
>>
> I'd prefer to defer any support for server-side quality-of-source until
> a later revision of the spec. Having different implementations doing
> different things is likely to cause application portability issues.
For all application that do not provide q-values (respectively q-values
of 1) the result would be predictable for all implementations. I don't
think that allowing implementations to provide a better format than
following the current spec for application that support this by
providing q-values causes a significant compatibility issue
>
>>>> If multiple media-type result to the same q-value product the one
>>>> that is not produced by a provider provided by the implementation is
>>>> used.
>>>>
>>> I don't understand, can you give an example.
>> This was an attempt to realize the second requirement of the following
>> assertion in the current spec:
>> "An implementation MUST support application-provided entity providers
>> and MUST use those in preference to its own pre-packaged providers
>> when either could handle the same request."
>>
> Sorry if I'm being dense but I can't work out if you think there's a
> problem or not ? The above requirement is there to allow applications to
> override the implementation-supplied standard entity providers.
Sorry for my unclear wording. I don't think there is a problem now. To
consistently resolve issue 46 the question if an application provided
producer with a low q-value is to be used instead of a pre-packaged one
with a higher q-value has to be answered.

Reto