qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: proton-c event test stable and fast for 5 billion messages
Date Tue, 25 Nov 2014 13:54:37 GMT
On 11/24/2014 06:54 PM, Fraser Adams wrote:
> That said with talk of new APIs I think that we should have a reasonably
> clear "roadmap", we've already got qpid::messaging and messenger, two
> separate AMQP 1.0 JMS clients not to mention potential confusion on the
> native python versus the python qpid::messaging binding (and don't get
> me started on QMF - three separate APIs depending on the language :'( )
> I don't think we've done a great job clearing up confusion arounf the
> differing APIs that we have.

I agree.

I've been working on some examples of using the engine API in python, 
along with some utility code to simplify the common cases and remove 
boiler plate. Though I mentioned this work on this list at the start, 
any conversation since has been on the user list (cc:ed, sorry for 
cross-posting) as it is of more general interest (so again I'd urge 
everyone who hasn't already to subscribe to that!). The work has been 
done on the 'examples' branch in subversion and now git, and I'm gearing 
up to submitting a patch for inclusion on trunk very soon. It was 
inspired by Ken's work on pyngus and Rafi's examples on github and has 
also benefited greatly from very helpful feedback from Alan, Justin and Ted.

The engine API is not new, though it has been recently enhanced by the 
addition of events. It has suffered from being hard (or tedious) to use 
though. The 'engine' on its own is not sufficient either and requires 
some IO mechanism; this is a strength in cases where an existing IO 
framework is in use, but a gap that needs to be plugged for the general 
use case.

The qpid messaging API does provide a simpler API than the previous 
engine API (the intricacies of the address syntax perhaps excepted!), 
but it does so at the expense of more limited control/capabilities. It 
also has some weaknesses when you want to build more genuinely 
asynchronous, reactive programs.

To me, the messenger api is similarly limiting and is in reality not 
that simple either. It also falls short for more completely reactive 

For the examples I've been working on, rather than hiding the engine 
behind the 'hard shell' of a new API, I've tried to supplement the 
existing API with some additional (optional) utilities (to which more 
can be added, allowing evolution to cover broader cases). The aim being 
to simplify the common cases while retaining the full flexibility of the 
underlying engine where needed.

Certainly for python, this is the approach I would choose myself and 
therefore the one I'd recommend for first consideration. I don't 
consider it a new API as such - though clearly there are some new 
exposed classes. I do think that it has the potential to provide a less 
confusing face to programming with AMQP.

Feedback of all kinds is welcomed as always, via any channel, though I'd 
like to conduct as much of the discussion as possible on the user list, 
as I believe this is of general interest to the whole community.

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

View raw message