qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: The future of Qpid Management.
Date Wed, 26 Feb 2014 21:38:17 GMT
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message