Hi Gordon, ----- Original Message ----- > From: "Gordon Sim" <g...@redhat.com> > To: us...@qpid.apache.org > Cc: proton@qpid.apache.org > Sent: Monday, May 19, 2014 11:25:41 AM > Subject: Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to > connect to a server without sending or > subscribing) > > On 05/15/2014 01:44 PM, Ken Giusti wrote: > > I think we should develop Messenger as an alternative client API to > > qpid::messaging, focusing on use cases that are not necessarily well > > covered by the existing qpid::messaging API. I think they > > complement each other nicely. > > In what way do you think they complement each other? >
I think you've touched on it below - they do differ primarily in style. But I think it goes beyond that. I think of qpid::messaging as being a "traditional" client api. It fits best in those scenarios where the application directly manages the connections (setup and fail-over), message sending/receiving, and credit. I suspect there's a lot of existing messaging systems that expect that kind of API, and will find qpid::messaging a better fit than Messenger. Messenger, as an alternative, provides (or at least promises to provide) solutions to a lot of the issues a "traditional" API has left to the application implementation. Things like connection failover, message retries, credit scheduling, routing, and even client-side store are provided by Messenger. Such features would probably feel cumbersome to someone looking for a JMS-like API (and IMHO may be better off with qpid::messaging), but for those folks who may not be bound to a legacy application, Messenger offers some useful features. > [...] > > I think we'd be much better off if we can separate the problem spaces > > these two client APIs attempt to address, and clearly communicate > > these differences so that users can find the right API for their > > particular use cases > > That sounds neat and tidy in theory. I suspect it is not so simple in > practice. > > > (example: connection oriented vs message oriented). > > I view that as more a question of 'style' than problem space. (I suspect > it also raises almost as many questions as it answers). > > The existence of alternatives is not itself inherently problematic. What > matters is how confident a prospective adopter feels when evaluating > options for AMQP and how easily he or she would succeed if AMQP were > embraced. It's not a question of eliminating choices, its a question of > improving the experience. > > [...] > > I think we should take an active role in promoting this new > > experimental, community-led APIs that you mentioned. To be clear, > > I'm not advocating that we (QPID) _support_ them, but I think we > > should add links to them directly from our QPID web site, along side > > the links to Messenger and qpid::messaging. > > I'm not sure what taking 'an active role in promoting' would mean, but I > confess it makes me nervous. For one thing the projects I linked to vary > widely in license, governance and maturity. > > On reflection and re-reading, my post was rather rushed and confused and > the list of links was perhaps a mistake. > > The central point I am trying to make, is that though there are a > variety of different *individual* initiatives, selecting an AMQP 1.0 > client one can have confidence in is still not easy and it seems to me > there is no real *collective* initiative to improve this. > Sadly, I have to agree. How do we (qpid) go about solving this? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K
