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: [email protected]
For additional commands, e-mail: [email protected]
