Marc,
> I think it would also be helpful to the group if you could explain
> the motivations and advantages of your proposition compared to the
> sketch2 APIs.
The motivation:
1) Answer to requests for some real use cases illustrating my previous
comments/suggestions.
2) Provide an alternative line of thought with the final goal of merging it
with your main line of thought.
3) I needed it to formalize and consolidate my personal thoughts in order to
consistently debate with the EG. I encourage other EG member with diverging
views to do the same, it is really helpful. BlinkSale API is an excellent
use case.
> E.g. you introduce the @ApplicationClass and @HostRef
> annotations but its not clear what their true purposes are beyond
> obtaining the host name from the URI which as Paul demonstrates below
> is already pretty straightforward to do without additional annotations.
The goal of the @ApplicationClass is also to mark a class that will handle
all serialization aspects of a consistent set of resources. I haven't fully
formalize the contract yet, but my views are very close to what was already
suggested in the list.
The @HostRef concept seemed helpful in the BlinkSale API case. I'm not fixed
on it. Paul's parsing is simple indeed but it could have been less simple in
the case where the URI is formed differently. In addition, it gives some
deployment information to the parent container.
Best regards,
Jerome