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.
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'll stop grousing now... :) ----- Original Message ----- > From: "Gordon Sim" <g...@redhat.com> > To: users@qpid.apache.org > Sent: Tuesday, March 19, 2013 11:19:03 AM > Subject: Re: [c++]: Progressing AMQP 1.0 support for 0.22 release > > On 03/19/2013 12:26 PM, Ken Giusti wrote: > > While the attached script looks very useful, would you consider > > adding those primitive commands to qpid-config instead? Rather > > than introduce a new tool, or adding new specialized domain/link > > commands to qpid-config. > > > > I like those primitives - adding them to qpid-config would make > > this de-facto qpid configuration command very flexible. (And > > would mean less work for the devs when new manageable type are > > introduced). > > I thought that might be confusing, i.e. having a tool that was a > mixture > of generic commands and more munged versions (add exchange v. create > exchange). > > However if this is in fact preferred, I'm happy to add it into > qpid-config instead of adding a new tool. Any other > views/preferences? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
