On Fri, Feb 20, 2009 at 4:17 AM, Gordon Sim <[email protected]> wrote: > 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?
I don't have an preference for any particular syle (ie --no-data-dir vs --data-dir=false). But I do think that having a consistent pattern is more important. Do we have to worry about being backwards compatible at this point? Even our client API's are not . So I suggest we sort this out now, before we get to that stage where we will be doing a 1.x release and gives the impression that we will be backwards compatible. Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
