I'm about to head out on vacation for 10 days or so, and haven't had a chance to read Rafi's document yet, but for the avoidance of doubt I'd just like to make clear that I completely concur with the position Gordon outlined below.
> 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. Proton is a (big) part of that effort in my mind, and I think our ability to contribute to the success of AMQP 1.0 would be (stupidly, unnecessarily) harmed by diluting our efforts into different "projects". -- Rob On 18 July 2012 20:05, Gordon Sim <[email protected]> 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. > > 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 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). > > 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. > > 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. > > 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. > > There is much to do! Let's get on and do it, remembering all the while to > talk about what we are doing and be open and welcoming to all who wish to > collaborate. > > --Gordon. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
