qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Date Thu, 21 Mar 2013 15:47:24 GMT
----- Original Message -----
> From: "Gordon Sim" <gsim@redhat.com>
> To: users@qpid.apache.org
> Sent: Thursday, March 21, 2013 11:47:38 AM
> Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
> 
> 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.

+1


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

-- 
-K

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


Mime
View raw message