On Mon, 2012-06-25 at 14:06 -0400, Justin Ross wrote: > On Mon, 25 Jun 2012, Rafael Schloming wrote: > > > The fundamental issue here is that Qpid now needs to serve two > > audiences. A very horizontal audience made up of pretty much anything > > that might ever want to speak AMQP, and a more specialized, vertical > > audience of people interested in a particular message broker. > > I accept that we have distinct audiences. I'm not, however, at ease with > binding "Qpid" to "a particular message broker" and "Proton" to the > future, and there being only two things, the old and the new.
I wouldn't be comfortable with that binding either, and I don't think anything that's been said has suggested this. I believe Proton is an important part of Qpid's future, but it's certainly nowhere near sufficient on its own. I think Qpid's future definitely includes a number of important components/sub-projects/what-have-you that build on Proton to provide key vertical functionality. > > I'd like to see a scheme like below (beware silly made up names): > > Qpid - Qpid is a leading implementor of AMQP; it has the following > components: > > - Proton - Proton is an AMQP protocol engine for use by integrators > > - Futon - Futon is a suite of messaging APIs [built on Proton] > > - Halfton - Traditional back-office brokers [built on Proton] > > In my view, the future of Qpid should be represented under the name "Qpid" > (with the brand redefinition that implies!), and things like Proton are > understood to be components of Qpid. > > I suspect that if we don't create an agreed, understandable scheme for the > different parts, then development will go to one stream or another simply > by developer inertia. > > Already, we have the new messenger API in Proton and the messaging API in > Qpid. How did you decide where to put it? To be honest I didn't really "decide" to put it there per/se, it just sort of grew up there because of demand from the current group of people interested in using proton. It makes sense that the people who are interested in using proton also want to see a simplified API to get their users started with AMQP 1.0. It really gives them an immediate ROI for integrating the engine. They give their users very simple and easy access from the very broad variety of languages, platforms, and environments that the messenger API can support. If we just put out a pure protocol engine for AMQP 1.0 and nothing more, then this is only valuable to people who already buy into the whole AMQP 1.0 ecosystem story. This defeats the purpose as the whole point is to pull people into that ecosystem who might not otherwise be interested. So their story really needs to be told together for the moment. Now that's not to say that as the AMQP 1.0 ecosystem grows or the messenger user base grows that their stories might grow more independent, and it might make some sense to separate them a bit more, but I would do that as the need arises. --Rafael --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
