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).
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]
