Alan Conway wrote:
It seems to me that regardless what happens there *will* be a JMS API
and there *will* be a Qpid API. The JMS layer has to call on something!
Currently there is no accessible AMQP API as I understand that term.
The question is whether there is real value in documenting multiple
ways for users to do the same thing in Qpid. I don't know the answer,
but I'd like to see some concrete examples of where people feel the JMS
API is inadequate,
How about setting up a single queue with several bindings?
inefficient or just repulsive, and how we could do
such a better job in Qpid that people would find it worth their while to
learn a new API and write code they'll never be able to port to another
JMS implementation. I'm not saying it can't be the case! I'm just
curious about the innovations people have in mind for Qpid's API.
Those innovations may come from other people and having the basics of
the protocol directly available makes it possible for them to do that.
We don't have to anticipate every innovation.
The point of the AMQP API is not that it is more efficient or less
repulsive but that it more directly reflects the protocol. JMS has its
model, which will be what the majority will be familiar with and use.
AMQP has its own model so why not have an API that reflects that model
more naturally?
