small correction I am definitely not saying that JMS is the majority of the use cases should be changed as I am definitely not saying that JMS is *not* the majority of the use cases
-Rajith On 9/18/06, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
+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? >
