From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 10 Apr 2007 14:36:42 -0400

On Apr 10, 2007, at 2:10 PM, Jerome Louvel wrote:
>
>>>> None of those helps when the return type can't be modified and the
>>>> media type isn't know in advance.
>
>>> In this rather unlikely case, it could simply rely on a wrapper
>>> POJO that
>>> would get annotated and would know how to "dynamically
>>> serialize" the wrapped POJO.
>
>> Its not an unlikely case, see APP, WebDAV, Amazon S3 etc.
>
> True, but the implementation of those use cases based on
> *unmodifiable*
> classes does seem unlikely.
>
I disagree, I could see Representation<File> or
Representation<InputStream> being used in those cases.

>> I think you missed my point. Adding additional properties to an
>> annotation requires slightly different syntax even when those
>> additional properties have default values.
>>
>> BTW, in other threads you've already suggested a number of
>> additional
>> annotations (e.g. ParentRef, RedirectRef, @Location,
>> ContentLocation,
>> Context) - as we explore use cases I'm sure that number would
>> grow ;-).
>
> @Context could be replaced by a more generic @HttpParam (@Param
> would be
> better IMO).

More generic in what sense ? We did consider something like:

@Param(type=HEADER|QUERY|MATRIX|URI, name="...")

but in the end we went for separate annotations @UriParam("..."),
@QueryParam("..."), @HeaderParam("..."), @MatrixParam("...") for
mostly aesthetic reasons.

> @RedirectRef is strictly equivalent to "ContentLocation" and
> @Location.
>
But the two are different, Location is used outside of redirects,
e.g. with a 201 response. IMO it would be confusing to use some kind
of Redirect annotation where you aren't actually redirecting.

Marc.

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