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 14:48:48 GMT
On 05/21/2014 02:10 PM, Ken Giusti wrote:
> I think of qpid::messaging as being a "traditional" client api.
> 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,

Automatic failover and message retry *is* supported in qpid::messaging 
(it isn't yet in Messenger).

> credit scheduling,

What is that exactly? Messenger::recv(N) essentially distributes N 
credits across however many incoming links there are, right? Whereas 
qpid::messaging allows capacity to be set per subscriber and maintains 
the window of credits accordingly.

So is the key difference here that in one API the credit is controlled 
per-subscription whereas in the other it is controlled in aggregate.

Where the number of receivers is larger than the number of messages the 
application is prepared to accept, dealing with the credit in aggregate 
and having it automatically (re)distributed as needed may indeed be 
useful. Of course the same feature could easily be built as a utility on 
top of something like qpid::messaging.

> routing,

So by this we mean the fact that Messenger looks at the address 'to' 
field of the message, applies some optional rules to that, and then find 
or creates the link to send it over.

This could of course also be built on top of qpid::messaging (or indeed 

> and even client-side store are provided by Messenger.

When you say 'are provided' you mean 'might be provided in the future'?

> Such features would probably feel cumbersome

I don't think it is the 'features' that are cumbersome, it's the 

> 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've heard this sentiment in different ways quite a lot. I.e. 
qpid::messaging and JMS are 'legacy' approaches, are for people who 
aren't free to choose etc, whereas Messenger represents the future, the 
ideal if nothing holds you back etc.

I don't go along with that view personally; I see nothing that really 
justifies it. It also seems to me to be quite counter to the notion that 
the APIs 'complement' each other, at least in my understanding of what 
that means[1].

I'm certainly not arguing that qpid::messaging is the ideal API either, 
or that there is only room for one API. I'm keen to see if we can 
improve the general situation and feel that some debate around the 
different visions that exist within the community would be helpful in 
enabling better collaboration on that goal.


[1] complement, verb, /ˈkɒm.plɪ.ment/:

     "to make something else seem better or more attractive
      when combining with it"

(from http://dictionary.cambridge.org)

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

View raw message