Hey guys.
I'd like to offer my input, but I'm kind of buried by the complexity
of the thread. It's difficult for me to determine what level of
consensus we've reached (if any) and what that consensus is.
Could someone sum up the current status of this thread?
-Ryan
On 4/10/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> 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.
>
>
>
>