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
programs.
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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
