+1 to Gordons comments. We definitely need as API that reflects the protocol more easily for people who need that kind of functionality.
Two more use cases -------------------------------- I want to do a SCA/AMQP Binding for Tuscany and I would want to leverage the protocol artifacts using a more intutive API and not JMS or an extended JMS. There is also a JMS binding and if use the same interface then were is the differentiation factor? I also want to use AMQP as a protocol for Axis2. Now I really haven't though about this, but some of the unique features that AMQP offers maybe useful if they can be accessed using a more natural API than through JMS. I am definitely not saying that JMS is the majority of the use cases. What I want is that we cater to the use cases where people need to deal with the protocol directly. If somebody has a need for that, then they will jolly well make it their business to learn the API :-) Regards, Rajith On 9/18/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
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?
