On 4/13/07, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
>
> On Apr 12, 2007, at 10:39 AM, Jerome Louvel wrote:
> >
> >
> I interpret this to mean that we should provide enough of an API
> (high or low level) to meet what the EG decides is a useful 80/20
> point and provide some kind of escape hatch whereby an application
> can drop down to a container API to meet the other 20%. How we
> subdivide the 80% between high and low level APIs is another matter
> as is what qualifies as high level and what as low level.
One of the problems I see is that we seem to be focusing on the 20% as on
par with the 80% in terms of initial importance. Some animals *are* more
equal than others ;)
>
>
> Foo postFoo(Foo foo, @HeaderParam("Content-Language") String language)
>
> instead of
>
> Foo postFoo(Entity<Foo> foo)
>
> but I'm less convinced by
>
> MyInputStreamWrapper getBar()
>
> class MyInputStreamWrapper {
>
> @EntityBody
> InputStream data;
>
> @MediaType
> String type;
>
> @Language
> String language;
>
> @...
> ...
> }
>
> instead of
>
> Representation<InputStream> getBar()
I agree with this entirely. I thought we had reached (somewhat) of a
consensus that Representation<T> was a useful abstraction in cases of
dynamic metadata and that Entity<T> was completely unnecessary if metadata
were obtained via parameter-based injection. Thus in the typical case,
everything could be a plain pojo (returned or consumed) but in certain cases
Representation<T> could be used as a dynamic metadata wrapper. No
Entity<T>'s.
A compromise would be to define the @EntityBody, @MediaType, etc
> annotations and then define a standard Representation<T> class using
> those annotations.
I dont like this, if you're going to provide everything thru annotation
hooks, then just do that--there's no need for a general case pre-annotated
class and IMO it confuses the matter (either people will never use it, or
they'll never use any alternative--either way leading to abuse).
I'd rather have the interface as an alternative.
>
> I think this is going to be a sticking point. I think we should be
> free to use classes/interfaces in this JSR where they make sense. I
> don't think its reasonable to exclude use cases purely on the grounds
> that their requirements are better met with classes/interfaces than
> annotations.
I agree in the sense that we shouldnt rule out classes and interfaces, I
dont find anything *wrong* with them inherently.
However, I think the spirit of Jerome's point (as I read it) is dead
on--that we should encourage simple, high-level use of POJOs wherever
possible (i.e. the 80% of cases), driven by annotation hooks.