On 31 October 2016 at 16:06, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> 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? > I was going to bring up a similar question - do we believe we are actually getting benefit from trying to keep the API of Proton-J and Proton-C "identical"? It's been a while since I worked on it, but my feelings at the time were that the enforcing of API identity (rather than equivalence) actually made proton-j much less natural to use and not insignificantly more difficult to maintain. I'd certainly like to see something with functional equivalence between C and Java, but it seems like we've actually fallen far behind on that with the lack of a reactive api. In terms of moving Messenger out of core in C and simply removing it altogether from Java, I think those are sensible steps that will help the user community better and make our offerings more easy to use and comprehend. -- Rob > > 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 > >
