Clebert,
Many thanks for your comments (especially the phrase "it looks great"!)
On 17/02/2012 17:06, Clebert Suconic wrote:
> Sorry for the late response, and sorry for being a bit inactive on these past few weeks (for personal reasons.. I'm sorry).
>
> Anyway.. I read the draft spec, and it looks great.. however.. a few observations:
>
>
> - I had a few talks with other people at RedHat internally before, and we believe that's about time to deprecate domain
> specific models (QueueConnection, TopicConnection...etc). If we don't deprecate it now we will be stuck for an extra
> number of years. I'm not talking about removing it.. just deprecating it.
Yes, this is
http://java.net/jira/browse/JMS_SPEC-47 which is in my list of "didn't make it into the Early Draft and
have been deferred until the next draft (the Public Draft)". So this hasn't been forgotten.
(Reminder: there's a link on the front page of the wiki which lists these issues)
I'm not sure exactly what we can do here, given that we can't remove it in this or a future release of the spec. But we
could at least clarify our intentions in the spec and javadocs. We'll come back to this shortly.
> - I would probably change the order on the Simplified API and possibly rename it. Maybe move it to item 6 and call it
> JMS 2 NEW API... or.. maybe Unified Model.
> I just got the impression that's being showed as a less powerful possibility for usage, while it's an evolution of the API.
>
> I just thought about it having more emphasis on the doc instead of looking like an optional addendum.
I think we need to come to a decision over whether the MessagingContext API should offer the same features as the
"standard" API, or whether it should only offer a subset. I think the most important issue which affects this is whether
or nor the MessagingContext API should support multiple consumers on a session.
Recent comments to this group recently seem to support the idea that the MessagingContext API is a simplified subset,
and that users wanting to do "advanced" things would need to revert to the standard API.
However if we decide to allow the MessagingContext API to support multiple consumers (with separate objects to represent
the consumers) then it would constitute a complete API which we could present as an evolution of the existing API.
I hope this is something that we can solicit community feedback on when we publish the early draft.
(As for the spec document itself: I agree the simplified API is currently presented as an "add-on" at the end of the
spec. That is for practical reasons: whilst the API is still being debated, and whilst we're still making changes, it's
best to keep it all in one place. However once we are confident we've got the API right I will try to merge it better
with the rest of the spec)
Nigel