On 07/18/2012 08:13 PM, Rafael Schloming wrote: > 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.
That seems like I fine goal to be a sub-project of qpid > >> 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 disagree, many project have not tackled the issues many messaging projects have, and thus it is valuable to have a broker that serves the user and also pushes on some of the technological boundries. Qpid in many cases has introduced many other project to such capabilities. > >> 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. Building a broker is part of the qpid mission, but providing protocol libs, clients libs etc are also. technically we could structure the protocol work (proton), client libs, qmf etc into sub-projects.... >> 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? > they are all governed by the TLP Qpid. they can each have there own goals, etc and once they have a user base it becomes appropriate to create lists etc once the traffic get to that point... I believe that was the reasoning we used when qmf was debated in this light. Carl. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
