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. > We as a community has a duty towards our users. And it is from this > pov that I'm not so sure about if we want to add the Java QMF > implementation *as it is without further discussions*. > As someone with a strong interest in the Java Broker, I am personally happy to sat that I want to add the Java QMF implementation. The work in the Java Broker to allow for such plugins was in some sense driven by the desire to encourage such work. -- Rob As Rob said, your contribution could be the basis for the new > management work. So again please don't feel discouraged. > > Rajith > > > Regards, > > > > Rajith > > > > On Mon, Mar 25, 2013 at 2:32 PM, Fraser Adams > > <[email protected]> wrote: > >> Hi Ted, > >> I was torn between extras and tools. I guess what sold me on tools at > the > >> moment was because I've noticed that a ruby subdirectory has just been > added > >> there, so having a Java one too seems to make some sense. Also as part > of > >> the Java QMF stuff I've done I've striven to add ports of the > "canonical" > >> python tools (such as qpid-config). Now partly that's perhaps > superfluous, > >> but it does provide good illustration how to use the QMF API. > >> > >> I'm a bit concerned that extras might be viewed a bit "second class > citizen" > >> and as I say it was the ruby stuff now in tools that swung it for me. > >> > >> If there's strength of feeling that extras is more appropriate then > that's > >> fine and I'll be OK with that, but then the location of the ruby stuff > seems > >> inconsistent (I'm not knocking the ruby stuff, just trying to figure the > >> most consistent place). > >> > >> The "stand alone project" thing is interesting, there was talk of this > for > >> QMF last year but it didn't sprout wings, and I guess probably won't. > >> Perhaps it might be time for a proper concerted think about > "management" in > >> general. Rob looks like he might announce some stuff from OASIS on AMQP > >> management in the near future, so perhaps the time is ripe to move all > the > >> management stuff into a new space to start the ball rolling on that > general > >> trajectory? > >> > >> I haven't made a proper start on this yet 'cause I ran into issues with > the > >> Java broker plugin stuff changing :-/ so I probably won't be able to > make > >> progress for a week or so 'cause I'm just about to go on holiday. I'll > have > >> email access but no development IT, it'll be good to have a discussion > on > >> management in general and what the thinking on the more "strategic" > picture > >> is. I think it's a good time to start this discussion, it's probably > overdue > >> given the divergence between the C++ and Java brokers. > >> > >> Frase > >> > >> > >> > >> On 25/03/13 12:54, Ted Ross wrote: > >>> > >>> Frase, > >>> > >>> Another possibility is qpid/extras/qmf. That's where the Python > >>> implementation is. We've used the extras directory as a place to put > more > >>> layered functionality, or things that might someday become stand-alone > >>> projects. > >>> > >>> -Ted > >>> > >>> On 03/24/2013 03:15 AM, Fraser Adams wrote: > >>>> > >>>> Hello all, > >>>> I'm looking to commit the Java QMF2 API, tools and GUI that I've > hitherto > >>>> had as tarballs here > >>>> > >>>> https://issues.apache.org/jira/browse/QPID-3675 > >>>> > >>>> It's all pretty self-contained and although has dependencies on the > Qpid > >>>> Java it doesn't impact anything in the main code base. > >>>> > >>>> My preference for location would be in qpid/tools/src in a new > >>>> subdirectory java which would seem to fit in given that there's a new > ruby > >>>> subdirectory that's just been added. > >>>> > >>>> Does that seem reasonable? > >>>> > >>>> Regards, > >>>> Frase > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> 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] > >
