Marc Hadley wrote:
> On Aug 14, 2008, at 10:13 AM, Reto Bachmann-Gmür wrote:
>>>>
>>> The spec says that media types for resource methods or
>>> readers/writers are sorted before comparison. For readers/writers see
>>> section 4.3.2:
>>> When choosing an entity provider an implementation sorts the available
>>> providers according to the media types they declare support for.
>>> Sorting of media types follows the general rule: x/y < x/* < */*, i.e.
>>> a provider that explicitly lists a media types is sorted before a
>>> provider that lists */*. Quality parameter values are also used such
>>> that x/y;q=1.0 < x/y;q=0.7.
>> I understood this text as quality parameter being the secondary key.
>> But the algorithm (section 3.8) for determining the media type uses
>> the q-value as primary key. I think using the specificity as primary
>> key for producers would have the advantage that implementations could
>> provide multiple type specific providers with different q-value
>> overriding the default ('*/*', no @Produces) providers.
>
> That would switch the precedence specified by HTTP. I think what you
> want is already supported, a provider with Produces(*/*) would be sorted
> after one with a more specific Produces. Maybe I'm missing your point,
> can you give an example of what you'd like to see supported that already
> isn't.
>
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.
I propose we remove it.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109