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
