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 applications. [Thanks to Robbie for his review and improvement of these comments.] Justin
