Gordon Sim wrote:
We have two forms in use for boolean options to qpidd. The first form
is where the presence of an option implies that its value is true. E.g.
--no-module-dir
--no-data-dir
--tcp-nodelay
--require-encryption
-t --trace
-d --daemon
-c --check
-q --quit
-h --help
The second is where the value for the boolean follows the option. E.g.
-m --mgmt-enable yes|no
--auth yes|no
Does anyone have a strong view on the desirability of making this more
consistent? I myself have a slight preference for --no-auth over
--auth no; I'm less bothered about the --mgmt-enable option but that
could be --no-mgmt.
I prefer the --auth yes/no style, as the "presence" style is a bit awkward for
config files and environment variables. E.g. it's not obvious that
QPID_TRACE= ./qpidd
is *enabling* trace. Similarly having entries in a config file with no value or
an empty value is a bit strange.
I'd make an exception for
> -d --daemon
> -c --check
> -q --quit
> -h --help
because these are really process control flags, not configuration. They don't
make sense in a config file or as env. vars.
For --no-data/module-dir I think I'd prefer it replaced by a special value of
e.g. --module-dir=no
The next question is whether - if we do change these - we should also
keep the original options for backward compatability?
I'd prefer not to, I guess it depends on the user impact. If most users are
using "service start qpidd" as recommended then that takes care of command line
args. We could provide a simple tool to migrate config files.
Note that it will be awkard to support both --tcp-nodelay and --tcp-nodelay=yes
at the same time, I don't think the standard boost option parsers will work that
way.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
