On 26/02/14 21:38, Gordon Sim wrote:
On 02/26/2014 08:00 PM, Fraser Adams wrote:
On 26/02/14 11:43, Gordon Sim wrote:
That said I don't believe one single source of information is ever
likely to be (and remain) sufficient for a tool that can be used with
multiple different brokers (there will always be 'extensible'
elements, such as the queue-declare 'arguments' for which you will
need to consult some other source of documentation).
Perhaps, though I'd argue that it's just a recursive type - so you
supply a Map parameter and describe the properties of the Map and their
types. Ultimately to be of use this stuff has to be described
*somewhere*, making said documentation *structured* doesn't then seem
unreasonable.
Just to be clear, I wasn't saying that such information *couldn't* be
defined in a broker specific schema, just that there isn't going to be
one document (schema or other) that has all the extensions for all the
brokers in it.
I'm probably on a losing streak with this, but at least you guys know
where I'm coming from now, if there are better approaches to document
this and better ways to make sure that said documentation does in fact
happen then I'll go with the flow.
Neither am I in any way advocating for or against schema retrieval
mechanisms.
I do think a generic tool for in some way 'managing' - e.g. like
qpid-config add|del|list or a gui equivalent - a range of different
brokers, each with divergent but overlapping sets of semantics, is
both feasible and (potentially) useful. I'd be interested to hear
other opinions on that though, especially with regard to usefulness.
I'd agree that it's a difficult one. My gut feeling is that with the
right sort of schema (and perhaps by "right" this includes annotations)
then at the very least it will be a whole lot easier to write more
general tooling.
I think it could certainly provide some 'dynamic' documentation,
tailored to the broker in question.
It's not black and white by any means - for example I
look at management-schema.xml and look at the QMF GUI and I've made
"judgement calls" on some of the properties that just take up real
estate and those which are useful and TBH I have "coded" pages for
specific Node types, but I do often wonder if I could make things more
general.
This is somewhat similar to qpid-config, though it also adds some
unnecessary (in my view) specific code to give different special names
to some options. However it does now also have a fallback to something
more completely generic (which I wanted for some of the new entities I
was experimenting with). It would in this context by noce to be able
to do something like e.g. qpid-config schema to get a list of the
supported types and their attributes... a dynamic usage statement,
driven by the broker connected to if you will.
Perhaps the differences between the C++ and Java Brokers gives us a
chance to figure out if it's actually possible to do useful "generic"
tooling.
Haven't you to some extent already done that with your QMF adapter
work? Not that I'm saying that adaptation to QMF is the way forward,
just that its possible to present a reasonable unified impression over
the two, even though they aren't entirely unified in reality.
Yeah I'm *relatively* content with how that turned out, as you know in
part at least what I did was intended as something of a "statement" to
illustrate that this sort of thing was possible and probably a good
thing, though I won't pretend it's perfect.
With a lot of what I'm saying I'm trying to be deliberately provocative,
as I said in my earlier mail it's *really* the fact of having decent
documentation that I care about, but I think that there needs to be some
sort of "forcing function" to make this more than just a "nice to have".
I've got some sympathy with Rob's comments "The basic operations are
fine and work OK out of the box... but what one might consider the
"bespoke" operations really don't because although the meta-data exists
it's really not enough to build a useable user interface... Sure the
parameter is a String, but actually it has to come from a constrained
type.."
TBH I'm actually no great fan of things like JMX Consoles for a lot of
the reasons mentioned and clearly the QMF GUI is itself "bespoke" - it
clearly does slightly different things for Exchanges and Queues and,
well Bindings needed a *whole bunch* of thought to try and figure out
how to represent them :-). But that said I suspect that AMQP Management
Agents/Manageable Entities although fairly general aren't likely to be a
general as say Java Objects and are likely to follow a relatively few
"patterns" so with decent annotations I have a feeling (but no proof)
that it'd be possible to have something fairly general that still looks
"nice".
On Rob's "Sure the parameter is a String, but actually it has to come
from a constrained type.." actually I think that XMI would allow you to
describe this sort of thing - though it wasn't really a serious
suggestion more just a bit of interesting food for thought (I wouldn't
want to generate XMI by hand) :-)
I mentioned previously that I think that the biggest source of real
awkwardness is in the area of associations between Manageable Entities
and how one goes about navigating.
In the QMF UI there was a fair bit of effort put in to making this sort
of thing efficient, so I pulled in the Objects I cared about and indexed
them in a Map so that reference properties could be dereferenced easily
and cheaply, being able to navigate from say a Queue to a Connection or
vice versa is fairly useful to me, but it's not especially simple and
that was one of the more interesting aspects of doing the mapping from
the Java Broker's internal Management Model to QMF.
So to get back to your point "Haven't you to some extent already done
that with your QMF adapter work" well yes, but it's not actually a
simple yes/no answer. The core properties/attributes all map fairly
easily and I could probably have got away without actually mapping those
because I introspected the names (I'll say why I did in a bit) but I
*certainly* needed to do something about the navigation because QMF and
the Java Broker Management Model take very different approaches. That's
why I'm a little troubled that AMQP 1.0 Management is agnostic about
navigation/association that's one of the hard bits and if everyone does
their own thing then it'll make it very hard indeed to create tooling
that's not very bespoke.
As it happens I actually mapped the properties because I was keen to see
if I could get it to work with the CLI tools such as qpid-config (as I
say it'd probably have looked decent with the UI with only the
navigation mapped). I mention that because I think migration from
existing tooling is going to be one of the more "interesting" aspects of
moving to AMQP 1.0 Management. So as you know I did a Java Broker
plug-in that does the mapping 'cause that was a fairly obvious place,
but if both C++ and Java Brokers talk AMQP 1.0 Management there's no
obvious place to do mappings - I guess that the best hope in that case
would be something like the client side of qpidtoolibs and similar for
Java and C++, but I haven't though too hard about it yet (it's likely to
need to happen in multiple places though rather than in the one place it
currently happens).
You'll recall a few threads on "Plans for QMF v1 and v2" last Easter
that were spawned on the back of plans to disable v1 push messages from
qpidd by default and the resulting realisation that the Python
asynchronous API only really worked for v1 at the time. I think that's
probably the tip of the iceberg compared to migrating to AMQP 1.0
Management. Perhaps the right answer is not to migrate but rather make a
clean break with new tools? I don't know, do you guys have a preference?
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
