On Mon, Mar 25, 2013 at 4:45 PM, Rob Godfrey <[email protected]>wrote:
> On 25 March 2013 21:32, Rajith Attapattu <[email protected]> wrote: > > > On Mon, Mar 25, 2013 at 2:50 PM, Rajith Attapattu <[email protected]> > > wrote: > > > Actually I'd like to take a step back and ask what are our plans for > > > QMF and management in general. > > > Fraser, this is in no way to discourage you or devalue your current > > > contribution. > > > But as you rightly pointed out in the later part of your email, we > > > should look at the bigger picture and see if we can align our selves > > > with the AMQP working group effort. > > > > > > From a community perspective, I'm not too keen to have our users to > > > start using java QMF given the uncertain future. > > > It might be a disservice to them. > > > But on the positive side, your contribution has forced us to discuss > > this again! > > > > > > To address this again. Currently QMF is the only potential common "API" > for managing across the two brokers. The emergence of a standardized AMQP > 1.0 management may mean that we can change the underlying protocol being > used by tooling, and offer us the chance to provide tooling that works > against a greater number of implementations... But if Fraser can get his > code to compile against the moving goalpost that is the Java codebase, and > check it in to the Qpid project, then I think we can quite happily say that > we will continue to support it going forward until such point as everyone > is happy that alternatives such as AMQP 1.0 Management completely supplant > the QMF functionality. > > > > To further explain, we introduced the Qpid Messaging API and we have a > > whole bunch of folks using it. > > However there seems to be question marks about the future of it given > > the emergence of Messenger. > > > > > To my knowledge there is no doubt about the Messaging API. It is > continuing to be supported and I believe Gordon is doing excellent work in > adding a 1-0 back end for it. > +1 One of the primary goals of the messaging API was to provide users with a seamless transition from 0-x to 1.0. There really are no question marks about its future in this regard. As one of the designers of both APIs I can confidently say they are quite a bit more different than people tend to realize at this point. I think we need to be careful not to encourage people to lump them into competition with each other, and it's certainly inappropriate to be casually spreading FUD about the future of the messaging API or any other qpid component. --Rafael
