On Apr 10, 2007, at 1:52 PM, Jerome Louvel wrote:
>
>> ... and therefore its important to provide a way to specify this
>> additional metadata. Again, I think the generic wrapper class is a
>> better solution than requiring developers to define their own
>> wrapper or subclasses whenever the metadata can't be statically
>> inferred.
>
> Expressed in this way and for this sole purpose, I don't have strong
> objections. I would just suggest to not rely on this wrapper class for
> default examples as it implies that this is the recommended way.
>
Understood. In examples there's always the temptation to throw in
everything to show all the features of the API but that can tend to
confuse rather than educate.
> Looking more closely at Entity<T> and Representation<T>, I don't
> see the
> need for Entity<T> interface. It also has the inconvenient of being
> fragile.
> Once we have a first public version of it, we can't add any method
> without
> breaking implementing classes (beside Representation that we
> control of
> course).
>
No, only JSR 311 implementations are expected to implement Entity<T>
so its OK to add new methods in a later revision of the API.
Representation<T> is concrete, so again its OK to add new methods
since a revised 311 impl will support them.
>> We can define classes and/or annotations for common headers but I
>> think we also need a general mechanism - I don't want to define an
>> annotation for every possible HTTP header.
>
> I fully agree.
>
OK.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s