I don't think there is anything too surprising in what you said, given previous discussion and how things have actually progressed over the past couple of years.
Messenger is covered upon in your comments, but slightly more in relation to the proton-c (+bindings) side. I think its worth going further and considering Messenger in proton-j a bit more distinctly. It has never really had much love, appearing to get written later in the day for completeness and having had little attention since, even while the equivalent in proton-c still did. Looking at the messenger-centric bits of the proton-j tree there seems to have been only 10 commits in the past 3 years (the easily viewed segment) with 4 of those essentially no-ops as far as 'activity' goes. In addition to the various Messenger issues you touched on, its worth adding that 'messenger-j' still can't do any form of SASL except anonymous. While I think the proposal to transition 'messenger-c' out from the core (well, the opposite really) makes sense given its history, for 'messenger-j' I think the better thing to do would instead be to simply remove it immediately. Note that this may be more complicated than it sounds given the python test suite, but at the very least removing it as a released component should be simpler, and I would argue, more helpful to everyone. Taking this slight disparity in approach a step further, I think its also worth asking if we shouldn't make proton-c and proton-j independently releasable components in concert with this work, as we have with many other components over the recent years (starting originally, with proton itself). I don't think the coupling has really had the desired effect or particularly done either significant good over the years, arguably the opposite at times. Whilst they are certainly much closer than other components we have made independently releasable, I think many of the same arguments for doing so still apply in this case also. Would anyone particularly disagree there? Robbie On 31 October 2016 at 12:54, Justin Ross <justin.r...@gmail.com> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
