On Mon, Mar 25, 2013 at 3:25 PM, Fraser Adams <[email protected]> wrote: > Did I tell you how much time I've expended on all this work?? :-/ > > > it's certainly pretty discouraging. It wouldn't be so bad except that I'm > not aware at all of any mechanism other than QMF yet in place to control the > C++ broker and I personally feel the JMX approach on the Java broker is > flawed (certainly it's somewhat Java centric and at least QMF uses AMQP as a > transport).
I'm really sorry. I know the feeling. I for one certainly value your contributions to the project and your perseverance and patience with us. As Gordon said, please don't be discouraged. I'm not saying we should throw away your hard work. It's not your fault that we are in this situation. All I want is a discussion about our management strategy and then see if we should commit to this path. We already have two brokers that have diverged quite a bit. We have a collection of management tools that doesn't play nice with both brokers. I'm worried about adding another to the mix given that the Java broker seems to have a different strategy for management. Again I apologize for this situation. Rajith > The REST approach is reasonable - as it happens the QMF stuff I've put > together has a REST Mapping to the QMF API, but ultimately I've become > pretty bugged by the lack of consistency between the two brokers and beyond, > which is something I've been trying hard to address. > > I'd have no problem migrating things to something new (sigh!!) but I really > think that the QMF Management GUI I put together is pretty good and I had > actually just got things working so that I could talk to both the C++ and > Java brokers using both qpid-config and the QMF GUI, that consistency seemed > pretty worthwhile IMHO. > > At the moment alternatives seem to be vapourware, so to my mind the real > disservice is leaving things in limbo. > > What I'm suggesting is actually about centralising management into it's own > area and using that to evolve towards whatever *unified* management turns > out to look like. There's no great reason why the existing API (plural) > couldn't be backed by alternate implementations as things evolve. Ultimately > both the C++ and Java brokers have pretty similar underlying internal > management "models" as borne out by the fact that it only took me a couple > of weekends to expose the Java stuff as a QMF Management Plugin. Unless > there's an intention to completely re-jig the internals a lot if this is > likely to be about how it is "externalised" off the broker, given that the > Java broker has just moved to a new management model is that going to change > again so soon?? > > > It's perhaps a little unfair to single out "Java QMF" as having an uncertain > future, surely you could say the same about the python stuff (or the new > ruby stuff)??? > > I'm more than happy to move forward once I know what trajectory that might > be, but I think that ultimately it's consistency that is really important > and we've got things dotted around all over the place. > > I'm just a little frustrated. > > Frase > > > On 25/03/13 18:50, Rajith Attapattu 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! >> >> 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] >> > > > --------------------------------------------------------------------- > 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]
