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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
