On 4/10/07, Jerome Louvel <jerome.louvel_at_noelios.com> wrote:
>
>
> Paul,
> > And MediaType can provide support for getting access to parameters on
> > the media type.
>
> I do see the value in the MediaType class. There is a very similar one in
> the Restlet API. But I don't think this class should be mandatory for
> POJOs
> annotated with the JSR API.
As for the MediaType class, I would prefer to see it directly added to the
> JDK (in java.net) rather than in this JSR so that other APIs and JDK
> classes
> could benefit from it, like the URLConnection class.
Even if this is not possible, the @MediaType annotation should be present on
ANY parameter indicating the mediatype for clarity.
>
> >
> > It seems like we are converging on a solution as Input/Output is very
> > similar to Consume/Produce.
>
> Indeed :) The advantage of @Input/_at_Output is that they can specify more
> constraints (language, character set, etc.) than the
> @ProduceMime/_at_ConsumeMime annotations.
Jerome: is there a reason you want the general I/O annotation versus a
specific Produce and Consume for Mimes, languages etc.?
I think for such a fundamental thing as content types and charsets, a
special annotation would be better than a catchall @Input or @Output.
Actually, I am in favor of the @MediaType annotation on parameter types and
methods to indicate production and consumption content types. This seems
more explicit in that you are indicating the the media type on the
(injected) parameter as oppose to @ConsumeMime on the method--which would
make more sense if the method could (also) consume content thru some other
way than as a parameter.
Or, are you saying @Input and @Output is intended on the entity class
directly?
Regards,
Dhanji.