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 Wed, 21 May 2014 21:02:51 GMT
On 05/21/2014 07:32 PM, Fraser Adams wrote:
> I guess that I'm fairly agnostic about there being two APIs, provided
> there doesn't wind up being a competition, and that we stop at two :-)
> I guess I'm slightly disappointed that the tone of this thread seems to
> be that it's something of a competition, I personally don't think this
> it should be and that each has a valid place. I think I'd prefer the
> energy to be spent making both as good as they can be :-)

I'm sorry you are disappointed by the tone. I don't actually view this 
as a competition between Messenger and qpid::messaging.

I've clearly not done a great job of expressing myself. The intent in 
starting this thread was to highlight the difficulty I believe is faced 
by any prospective adopter of AMQP 1.0 in selecting the API on which to 
start building their applications (I could perhaps exempt those who head 
straight for JMS) in the hope that an open and frank debate helps us 
collectively identify ways to improve things.

I am not arguing that there is only room for one API, and certainly not 
that qpid::messaging should be the only API. As a matter of fact, my 
personal belief is that those two APIs are not sufficient, neither of 
them being suitable for certain applications.

Choosing between the existing APIs is I think a small part of the 
problem, but that is because it is not clear what limitations a given 
choice imposes rather than because the choice exists.

Perhaps we've been reluctant to describe the choice in those terms 
because it seems negative or because it is emphasising gaps at a given 
point in time rather than intrinsic aspects of the respective designs.

However I think it is actually very important to users, and so its 
perhaps useful for us to try and list the limitations, if for no other 
reason than to see if there is a roadmap for resolution.

So here is an initial, non-exhaustive list of current shortcomings from 
me. Please all feel free to add to and correct this.


* boost dependency
* limited to windows and linux
* requires thread per session
* can't be integrated into existing event loop
* can't handle incoming connections
* no support for transactions
* sasl support in windows very limited


* no reconnect; no reliable way to handle it by application either
* no automatic message replay
* can't control lifecycle of links or connections (e.g. can't cancel 
subscriptions or close a connection that will never be used again 
without stopping the whole messenger)
* can't control source or target (can't use selectors, can't specify 
dynamic node-properties, capabilities etc)
* can't set or see connection properties
* doesn't handle errors well, e.g. authentication authorisation failure, 
node not found etc
* responds to incoming link attach requests by erroneously cloning 
source/target, regardless of whether it understands or supports the 
expectations represented
* no support for transactions
* sasl support limited to anonymous and plain

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

View raw message