Re: Issue 1: Adding additional conneg metadata to _at_Produce/ConsumeXXX

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Mon, 21 May 2007 09:53:19 -0400

On May 19, 2007, at 10:32 AM, Jerome Louvel wrote:
>> I'm therefore not yet convinced that adding a declarative language
>> capability is that useful in practice. I think the above does
>> illustrate a need for a "QValuedCommaSeparatedList" type to aid in
>> parsing of the Accept-XXX headers though.
> Like you, I'm not sure yet about the practicality of declaring those
> metadata as annotations. However, I think that we should protect the
> resource code from client preferences considerations like parsing/
> analyzing
> the Accept* headers!
I think we can certainly help with the parsing as I suggested.

>> (ii) Charset
> [...]
>> Unless I'm missing something there doesn't appear to be much use in
>> allowing a developer to declare support for a particular subset of
>> the platform supported charsets provided the 311 runtime uses the
>> platform facilities correctly when reading and writing data.
> This can be important to be able to declare the character set of a
> byte
> stream dynamically generated or read from a file.
I should have said "statically declare". For the file case you'd
presumably want to be able to set such information dynamically rather
than statically with an annotation.

>> (iii) Content Encoding
>> I don't really know enough about content encoding to judge
>> how useful
>> it would be to be able to statically declare support for one or more
>> of them. Can somebody give some concrete use cases that would
>> illustrate its benefits in our API ?
> You want to return a representation from a zipped file directly
> without
> unzipping it, while still allowing the client to know what's inside
> the
> representation to auto-unzip it.
That doesn't sound like something you could generally declare
statically since it would depend on the file to be returned and, in
the cases where you could declare it statically, I'd think you'd want
to serve the file directly rather than going through our API to do so.


Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.