Arnaud Simon wrote:
My point was really that we need to define what an AMQP Destination is
and its associated interface and semantics. We'll then provide a way of
configuring it from whatever configuration mechanism (It could be JNDI
or via provider specific properties). In that way we don't hide non-JMS
semantics but document them and keep AMQP JMS implementations
inter-operable. The point is really that AMQP should define what a
Destination is.
I think I agree with much of this, but for me a destination in AMQP is
not quite the same thing as a JMS-over-AMQP implementation of the JMS
Destination interface.
I believe that (ideally! [1]) the Qpid JMS client should be constructed
in such a way that you can get a variety of AMQP 'behaviours' [2] based
on the details of the Destination object you construct your Consumer or
Producer from. We've got the simple mapping handled reasonably well now,
but I think we could get more flexibility through some refactoring of
the code.
Perhaps in the future the 'official' JMS-over-AMQP mapping will define
this (or something else) as 'required' flexibility, but in my view we
should proceed with how we (the Qpid community) believe things should be
for now.
--Gordon
[1] I appreciate its easy to describe my wishes at a high level, and
rather more effort to actually make them possible. I will try and find
some time to think things though in more detail.
[2] E.g what exchanges to use, multiple bindings to a queue, whether and
when things are declared & whether the 'passive' flag is used when so
doing, whether the 'mandatory' flag is set on published messages,
whether the exclusive flag is set when issuing a subscribe etc. etc.
