On Wed, 2012-07-18 at 19:05 +0100, Gordon Sim wrote: > On 07/18/2012 05:40 PM, Rafael Schloming wrote: > > So while the Proton mission is in many ways compatible with the > > original Qpid charter, the de facto Qpid mission of today is really > > quite different from Proton's. > > I tend to disagree. > > In my mind, the purpose of Qpid has always been to develop software > under the ASF governance and licensing in order to support adoption of > AMQP and the emergence of an ecosystem built around it that better > serves users needs.
As I stated above, I agree that the Proton mission is compatible with the original Qpid charter, but I believe they are still quite different. The above statement permits the development of just about any kind of application that happens to speak AMQP since that furthers adoption of AMQP. The Proton mission on the other hand is about making it as easy as possible for any application (either existing or under development) to speak AMQP. This really doesn't include building any such applications as part of Proton, and doing so would compromise Proton's embeddability and neutrality. > At the time Qpid was formed, that meant client libraries and messaging > brokers. We have always wanted to have embeddable libraries that other > broker/clients/frameworks/etc could use to support AMQP however. > > As AMQP has evolved, a clearer, cleaner layering has emerged. The > specification defines how different components can interoperate, rather > than attempting to define the behaviour an interchangeable message > broker (which the earlier specifications did not in fact achieve anyway). > > In addition I think through developing and maintaining different > language implementations we have come to appreciate ways in which this > can be kept more manageable for maintainers and less confusing for end > users. > > The landscape is therefore different now than it was when Qpid began. To > my mind however the mission of the project is not, though we should > always be prepared as a community to re-evaluate how best to achieve it. I think the problem is that were we to reform Qpid in today's world, the best way to support adoption of AMQP would not be to build yet another broker, but rather to build a library that makes it easy to adapt all of the many existing brokers to speak AMQP. That is certainly very much where proton is aimed, but unless you're prepared to take the view that we should dump the brokers and ignore existing Qpid users, it's a stretch to say that the de facto mission is no different from the original as the de facto mission clearly involves doing something with the brokers we've built. > I believe wholeheartedly in the development of a protocol engine for the > three 'platforms' mentioned (C, Java and JavaScript). I believe these > should be usable by any higher level component that wants to speak AMQP > in some way, whether part of Qpid or not. > > It seems clear there is also opportunity for wide reuse of a 'driver' - > an IO subsystem as you put it - designed to work well with the engine, > for cases where that functionality is not already provided. > > I also fully appreciate and welcome the expanded understanding of the > 'API space' that these developments have brought into focus, though I > think there is still some thinking to be done there. > > As I stated on another thread, I think we need a shift in emphasis. A > renewed emphasis on interoperability, a new emphasis on enabling an > ecosystem that is wider than perhaps first imagined. > > To my mind this is not a change to the mission or Qpid, nor does not > necessarily negate the value of existing components (though again, we > should never be afraid to re-evaluate). To be clear, I don't believe I ever proposed any sort of change to the Qpid mission. My point is that the Proton mission is just different to the Qpid mission *of today* (if it were not there would be no point in doing it), and depending on what you think the Qpid mission is or should be, you may feel it is more or less compatible and/or overlapping with the Proton mission. For example, lot's of people think that Qpid is about building brokers, and that's pretty much entirely disjoint to what Proton is about. > An ASF governed, open, AMQP enabled JMS client is clearly a valuable > piece of the 1.0 ecosystem, as is a broker that can support the full > functionality that JMS defines. These should likewise be usable on their > own, against AMQP-enabled components developed outside Qpid, and outside > the ASF. They play a different role than proton in promoting AMQP, but > in my view are merely different initiatives supporting the same mission. What's the important distinction between initiative and mission? I certainly think you can interpret the Qpid mission as broad enough to include a lot of things, but that simply begs the question of what are the sub-missions/objectives/whatever of each initiative, and how are they governed when they have distinct sets of users? > I anticipate new behaviours and components that can be built on top of > the core AMQP protocol in the future and what better place to explore > and develop those than here at Qpid, under an established, well > respected governance model? I think we also have a responsibility, and > perhaps a unique position, to help bridge users of the earlier revisions > of AMQP onto the better world that 1.0 promises, the users that in large > part have fuelled that very evolution of the specification. How do you define what is in/out? If I write a chat server, distributed ray tracer, or MMO that happens to speak AMQP, is Qpid the perfect place to build these things? > What structuring makes most sense is something I think will become > clearer organically as we make progress. The key is - as always! - > continual, open communication and debate, not only amongst the > developers but with users in the widest sense. I think it's important to recognize that Proton needs to be *neutral*, i.e. it is a general purpose library that any application can use to speak AMQP. It can't favor any one particular application's usage of AMQP, for example Bundling together a JMS Broker with Proton would obviously give any existing JMS vendor pause if they were considering using Proton to support AMQP. So while it's all fine and well to paint a picture of Qpid as an umbrella project which is open to all things AMQP, that picture is missing an important distinction between software that underpins an ecosystem (e.g. the TCP stack), and software that is part of an ecosystem (e.g. an http server). --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
