Hi Mark,
> > It seems that you mix the ability to expose dynamic representation
> > metadata
> > and the content negotiation algorithm (interpreting the Accept*
> > headers).
> >
> I don't think its really a matter of mixing them, rather the runtime
> hands off to the application when there isn't sufficient static
> information to make a determination.
The conneg algo doesn't need to rely on static metadata only. It could
perfectly work on dynamic metadata too (like we do in Restlet).
> > For the first one, we should just have annotation ways to
> expose those metadata, and for some rare cases rely on an
> "EntityProvider" service.
> >
> I don't think EntityProvider is related to dynamic metadata. You can
> associate some static metadata with one (ConsumeMime, ProduceMime)
> but by the time an EntityProvider enters the process all of the
> conneg will have already taken place.
Why does it have to be processed this way? If you design the API for a
stricter separation between the resources/representations and conneg algo,
this perfectly possible IMHO.
> For "annotation ways to expose those metadata" do you mean something
> like an annotated method that would return, say, the list of
> available languages ?
Yes, and not only for languages. The notion of variant (consistent set of
metadata) is important too.
Best regards,
Jerome