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!
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, 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. Cheers, Alan. On Mon, 2006-09-18 at 11:06 +0100, Gordon Sim wrote: > Steven Shaw wrote: > > On 15/09/06, Robert Greig <[EMAIL PROTECTED]> wrote: > >> I think we agree that we need to expose functionality that goes beyond > >> JMS. The question is whether we can do this though extension points to > >> JMS or whether we need a separate API. > > > > Perhaps both. > > I agree with this view. The different ways of exposing functionality > need not be mutually exclusive. > > Support at the 'protocol' level makes it easier for the full flexibility > of AMQP to be exploited in perhaps unanticipated ways. > > As an example, pulled out the air, imagine a particular use case wants > to set up a single queue with several bindings. Rather that trying to > anticipate all these sorts of usage patterns from the start a more > directly exposed protocol layer would make these easy to compose from > the protocols own building blocks. > > However JMS is clearly the first choice for the vast majority of > messaging based systems written in java, so allowing these system to > exploit the protocol through API extensions or configurable semantics or > mappings is also going to be important.
