On 31 October 2016 at 17:28, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> On 31 October 2016 at 16:37, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > > 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. > > > > No, I don't think keeping API 'identical' has given benefit to warrant > some of the less natural cases. That said, I'm not sure its actually > tried as much as it was in the past either, since they have actually > diverged in API in cases already, e.g. SASL handling is entirely > different between them these days (though partly because proton-c > changed and proton-j did not). > :-) Yeah - that was my impression too... My intent here was really to see if we can better restate the goals of Proton-J in particular so that we focus on an equivalence and maybe at the same time then look to keep the two libraries closer in functionality (i.e. not leaving the Java libraries behind because it is a pain in the ass to try to write C code in Java) -- Rob > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
