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


Reply via email to