Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <5151DF4D.1070801@redhat.com>
Date: Tue, 26 Mar 2013 17:47:57 +0000
From: Gordon Sim <gsim@redhat.com>
Organization: Red Hat UK Ltd, Registered in England and Wales under Company
 Registration No. 3798903, Directors: Michael Cunningham (USA), Mark Hegarty
 (Ireland), Matt Parsons (USA), Charlie Peters (USA)
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
References: <403354247.17445814.1363871974412.JavaMail.root@redhat.com>
 <514B2B9A.5090500@redhat.com> <5151D5E2.6050100@blueyonder.co.uk>
In-Reply-To: <5151D5E2.6050100@blueyonder.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/26/2013 05:07 PM, Fraser Adams wrote:
> 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?

Yes. The current qpid-config needs to be updated for every type it can 
create, delete or list though the same basic mechanisms are used in each 
case.

Specific knowledge of types is useful in list as it can allow the exact 
fields displayed and their order to be more tailored. There is also a 
fair amount of option/argument 'munging' in qpid-config (in my view 
slightly less obviously justifiable).

> 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?

I do indeed! I would see it is almost too general. Though it does allow 
access to all QMF methods (e.g. queue purge etc), it does make using the 
create and delete methods a fraction more complicated. It also doesn't 
support listing objects.

> 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.

It is similar... my reason for not picking that was that I felt in 
hindsight it wasn't as usable for the cases I really cared about. I 
guess this all goes to emphasise the validity of Ken's point (and indeed 
the theme you have often mentioned) namely some coherent vision for 
management tools.

> I remember qpid-ctrl because I wrote a Java port of it in
> my QMF bundle.

You don't do things by halves! I admire your consistency!

> 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.

I think create and delete should really be 'built in' to a management 
mechanism, rather than being schema dependent as they are in QMF for the 
broker(s).


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