qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
Date Wed, 21 May 2014 13:10:02 GMT
Hi Gordon,

----- Original Message -----
> From: "Gordon Sim" <gsim@redhat.com>
> To: users@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message