Hi Gordon,
I was thinking about this thread earlier on today and something just
struck me about the general tool "for creating,
deleting and listing objects of any type" that you attached previously
and is being discussed here.
I think that the general premise is that it provides a more "general"
approach than say qpid-config because it's abstracting to the broker
create and delete methods and given that type, name and other properties
can be specified as a Map that gives a fair degree of generality - is my
understanding correct?
If it is then the thing that struck me is that there was already a tool
that provided this sort of behaviour (actually possibly even more
general) - do you recall qpid-ctrl?
It's not necessarily in the most helpful location "qpid/cpp/src/tests"
but it seems pretty similar to what you are describing here unless I've
misunderstood. I remember qpid-ctrl because I wrote a Java port of it in
my QMF bundle. It's been a little while since I looked at the python
version, but digging out the JavaDoc I put in my Java one I note:
* List the properties of the qmf.default.direct exchange:
* <pre>QpidCtrl -c exchange -i qmf.default.direct listValues</pre>
*
* Create a queue called test with a flow-to-disk limit policy:
* <pre>QpidCtrl create
"{type:queue,name:test,properties:{'qpid.policy_type':ring}}"</pre>
*
* Delete a queue called test:
* <pre>QpidCtrl delete "{type:queue,name:test}"</pre>
*
* Create a binding called bind1 between the amq.match exchange and the
test queue matching the headers name=fadams
* and gender=male:
* <pre>QpidCtrl create
"{type:binding,name:'amq.match/test/bind1',properties:{x-match:all,name:fadams,gender:male}}"</pre>
*
* Delete the binding called bind1 between the amq.match exchange and
the test queue:
* <pre>QpidCtrl delete "{type:binding,name:'amq.match/test/bind1'}"</pre>
Apologies if I've misunderstood the context, but I thought it was worth
mentioning given that the main thrust of conversation was about a
general way of controlling arbitrary objects.
Cheers,
Frase
On 21/03/13 15:47, Gordon Sim wrote:
On 03/21/2013 01:19 PM, Ken Giusti wrote:
Hmmmm... seems like there's not a strong opinion either way.
On reflection, I think I'm actually fine with your original proposal
(separate tool - very generic management tool). As a developer, this
tool would really come in handy - it allows me to manage newly
developed objects without the need to create a dedicated tool. Very
useful.
That is indeed the rationale behind the tool. It always felt wrong to
me that you need to add explicit code just to recognise another class
of object in qpid-config. (I also dislike the fact that it defines its
own names for options).
I think my overall unease is with the rather large number of
configuration tools that we support. I'm really not crazy about how
we tend to create a new feature-specific configuration tool every
time we add a new feature to the broker. I'd rather see a single
"top level" broker configuration command that supports all the
configuration aspects of the broker. Openssl and NSS (certutil) take
this approach. I think it would tend towards unifying the
configuration experience (e.g. naming of common options would be
consistent, need for familiarity with only one command, etc).
I'm a bit biased. Guess I've found myself fixing the same defect
across multiple configuration tools a little too often (*cough*, SSL
configuration *cough*). And I still keep having to remind myself
which option flag is used to specific a non-default broker address (?
is it "-a", or "-b"?).
I sympathise entirely. For me its less the number of tools per se and
more that there is no clear, comprehensive, thought out strategy
around them.
I don't want to make the situation worse. What I propose for 0.22 is
to add this new script into cpp/src/tests and install it in
libexec/qpid/tests along side other useful scripts and tools such as
qpid-send and qpid-cpp-benchmark. I'll also make it clear in the usage
text that the tool is experimental at this stage. That way its
available for those who want it, particularly those exploring 1.0
based networks, but its status is clear.
Does that seem reasonable for now? We can then get some more time and
feedback on which to base more long term decisions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
