qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@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 Mon, 19 May 2014 15:25:41 GMT
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 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 

> (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.

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

View raw message