Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <514B2B9A.5090500@redhat.com>
Date: Thu, 21 Mar 2013 15:47:38 +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/20130110 Thunderbird/17.0.2
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>
In-Reply-To: <403354247.17445814.1363871974412.JavaMail.root@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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