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.
>
>>> Accept: image/x-weird-format, image/png;q=.9
>>>
>>> the BodyWriter for image/* matches image/x-weird-format but will
>>> fail to produce that format and throw an exception. Had the
>>> mediatype been passed to isWriteable the BodyWriter could have
>>> detected that it doesn't support image/x-weird-format allowing the
>>> producer for next accepted format to be used.
>>>
>> The wild card reader can get access to the ordered list of
>> acceptable media types (via HttpHeaders) so could choose another
>> media type if the most acceptable media type is not supported. This
>> presumes that such a reader would support common formats, like
>> image/png in your example.
> The implementation would set the Content-Type response header to the
> wrong content-type, I think providers should never return another
> media type as the one requested by the parameter.
>> If we want the isReadable/isWriteable methods to have more
>> information then they probably require all parameters of the
>> readFrom/writeTo methods, minus those for the Input/OutputStream.
> I agree with adding media type, as it's not acceptable that adding a
> value to the Accept-Header of an otherwise successfully answered
> request could render the server unable to respond.
>
> Not sure if other headers should be able to cause the provider to be
> skipped in favor of another, Accept-Language maybe?
>
Agree with adding media type to isWritable, though really providers
should be specific about their capabilities and not use wildcards
unless they really mean it.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.