qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <justin.r...@gmail.com>
Subject Proton's road ahead
Date Mon, 31 Oct 2016 12:54:53 GMT
Hi, everyone.  I’m writing this to give you all a clearer picture of our
intentions for Apache Qpid Proton and to invite your feedback.  There are
several moving parts, so I’ll take them in turn.

Messenger and Proton APIs.  The Messenger API has been a source of trouble
for us for a long time.  It is attractively simple for some basic cases,
but once you step even a little outside the lines, it shows its
limitations.  There are many things that Messenger makes difficult or
impossible, including core aspects of API use such as error handling.

The reactor and Proton IO.  The reactor code wants to itself be the master
event loop, and this unfortunately makes it difficult for people to
implement some of the IO integrations that are desirable and in keeping
with Protons original goals as an AMQP 1.0 protocol engine -
language-native IO for bindings, native Windows IO, and use of popular IO
frameworks such as libuv.

We’ve been working gradually to tackle these two problems, at the top-end
user API level and at the bottom-end IO integration level.

Proton APIs.  In the past year we have expanded and matured the
event-driven (or “reactive”) Proton APIs, now offered in C, C++, and
Python.  These APIs are very well suited to building AMQP 1.0 integrations
and apps.  They give users full-spectrum control of AMQP, and they maintain
the virtues of Proton that we have always considered important -
asynchronous by design, no assumptions about threading, and minimal
dependencies. We don’t yet have an equivalent Java reactive API directly in
Proton, though adding one in future would be good. There are however
external framework integrations of the proton-j engine offering related
functionality that could in some cases serve such needs in the interim
where integrating the engine directly is deemed too onerous for folks.

Proton IO.  Work has been progressing on a cleaner IO integration API to
stand between Proton’s protocol state machine and a particular IO
implementation.  The integration API will ease use of the protocol engine
and facilitate using the event loop of an external library as the primary
driver of events.  For proton-c, we are pursuing platform-native IO
implementations for Linux and Windows as well as libuv. For proton-j, we
would look to make similar improvements to ease and improve use of the
engine with popular IO frameworks in addition to the built-in IO constructs.

With these changes it increasingly makes sense to separate out a Proton
core, with areas like Messenger and the reactor then acting as consumers of
that core, and we intend to work toward making the Proton libraries reflect
that.  In C for instance, this would involve isolating the core Proton
functionality (protocol engine, event-driven API, IO integration API) from
the additional APIs of Messenger and the reactor.  We would then offer both
a new libqpid-proton-core and the existing libqpid-proton library, where
the latter depends on the former and forwards its symbols.  Over time, we
can then migrate the language bindings and servers to also only use the
core library.

In a sense, this is about taking Proton back to its roots.  Proton is an
excellent engine for processing AMQP protocol state.  It’s built for fast,
asynchronous communication, and it’s designed to fit in any environment.
That’s what we love about Proton, so we’re proposing these changes so that
it can continue in that role for a broader set of outside libraries and

[Thanks to Robbie for his review and improvement of these comments.]


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message