We will never be able to completely cut off the "old" APIs, as there are just too much code still using it. Even deprecating the Queue/Topic-Domains will not be that easy with the general spec update policy in place, as Nigel has written down a while back.
I'm in favor to focus on the 99% use case and leave the esoteric requirements to the complicated legacy API that we still have to pull for a long time.
On 2012-02-20, at 22:21, Clebert Suconic wrote:
> 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)
>
>
> I would make it a complete API, whatever that means...
> Just because it feels a great improvement over the old API. I think we could present a great deal of innovation.
>
> As you said anyways, users will start asking for features anyways once we go to a public review.