+1 , I agree that we can add extensions where necessary and where it makes sense. However like Rob Godfrey says not everything can be exposed in a meaningful way. Also the mapping from JMS to AMQP has to be more clearer as Rob says.
The AMQP API can be used to leverage the finer points which cannot be meaningfully expressed by the JMS API. Robert Greig has already provided some of those examples. Regards, Rajith On 6/7/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
> What is your view on how any AMQP-specific features should be exposed > to end users (in Java)? Adding extensions to JMS makes sense where we identify a common use case for such an extension. Your case of the immediate flag is once such case. The ability to create "destinations" which are not queues/topics but arbitrary (exchange,routing-key) pairs OR (queues) makes sense. [The semantics of Destination, and in particular that the Destination you send to is the same as the Destination you receive from will be brokern, except for the two special cases of direct and topic exchanges]. Use of other content classes would be "interesting" :-) Exposing certain methods, Basic.get for instance, would have been difficult. One thing I think needs to be made clear in the AMQP spec are which "classes" are meant for end-user use and which classes are meant only for use by the "library". What I would like to see is that the use of certain JMS constructs do not have interesting side-effects. For instance currently in Qpid the declaration of a consumer creates a queue, whereas the declaration of a producer does not... I think the mapping of our JMS implementation to AMQP needs to be somewhat clearer... -- Rob
