qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Date Tue, 26 Mar 2013 17:07:46 GMT
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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message