Alan Conway wrote:
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.
Actually you can specify QPID_TRACE=yes, QPID_TRACE=true (or
QPID_TRACE=no, QPID_TRACE=false) and that is interpreted as you would
expect. I.e. QPID_TRACE=false does not turn tracing on. Likewise in a
conf file you can have trace=false. (Smart people those boost developers!).
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.
Indeed and writing custom value parsers seems like more effort than it
would be worth. I think the choice is either to make a non-backward
compatible change or leave it as is. There doesn't seem to be an
overwhelming dissatisfaction with the current state of affairs and it
seems like we don't all agree on the preferred change anyway. I'm
inclined to leave things as they are?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
