On 02/25/2014 10:35 PM, Jakub Scholz wrote:
I think the QMF and the tools around it demonstrate the problem of tools
modeled only according to some schema. Utilities like qpid-tool allow you
to find the schema details about the objects/classes and their methods and
call these methods. But if you want to use the filter in the purge method
of a queue object, it doesn't really tell you how should the filter
attribute look like.
It is of course great to be able to save development effort and to have at
least some tools. But the value of such tools to the end user is often
questionable, especially since it is often connected with missing
documentation.
You are of course correct. Sufficiently accurate and detailed
documentation is essential in order to allow users to use any tool.
A schema is a form of documentation which to be useful as such needs to
have descriptive elements within it (rather than just types and names).
In one sense the example with the purge filter highlights the fact that
the description for that parameter is not sufficiently clear. Any form
of documentation can suffer from the same deficiency.
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).
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
