You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2009/02/18 19:57:19 UTC
[c++] boolean options for qpidd
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.
The next question is whether - if we do change these - we should also
keep the original options for backward compatability?
Any thoughts or comments?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Jonathan Robie <jo...@redhat.com>.
Gordon Sim wrote:
> Jonathan Robie wrote:
>> Sometimes you think of a third possibility. I would rather change
>>
>> --auth (yes | no)
>> to
>> --auth (yes | no | permissive | inherit)
>>
>> than change:
>>
>> --no-auth
>>
>> to
>>
>> --no-auth | --auth | --permissive-auth | --inherit-auth
>>
>> So I prefer the "--keyword value" format for extensibility purposes.
>
> You've confused me (not difficult to do!). Are you suggesting new
> options? What would permissive and inherit do?
Oh, I have no idea. Those are examples of the kinds of options someone
might dream up 6 months from now. If we *do* dream up such options,
we're better off using the --auth (yes | no) approach now, so we can
easily extend the options if need be in the future.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Gordon Sim <gs...@redhat.com>.
Jonathan Robie wrote:
> Sometimes you think of a third possibility. I would rather change
>
> --auth (yes | no)
> to
> --auth (yes | no | permissive | inherit)
>
> than change:
>
> --no-auth
>
> to
>
> --no-auth | --auth | --permissive-auth | --inherit-auth
>
> So I prefer the "--keyword value" format for extensibility purposes.
You've confused me (not difficult to do!). Are you suggesting new
options? What would permissive and inherit do?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Jonathan Robie <jo...@redhat.com>.
Gordon Sim wrote:
> Does anyone have a strong view on the desirability of making this more
> consistent?
Consistency really makes it easier to remember these things.
> 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.
Sometimes you think of a third possibility. I would rather change
--auth (yes | no)
to
--auth (yes | no | permissive | inherit)
than change:
--no-auth
to
--no-auth | --auth | --permissive-auth | --inherit-auth
So I prefer the "--keyword value" format for extensibility purposes.
> The next question is whether - if we do change these - we should also
> keep the original options for backward compatability?
Probably. Depends how much the users would squawk if we didn't. I'd much
rather clean it up and drop the old options if we can get away with it.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Alan Conway <ac...@redhat.com>.
Rajith Attapattu wrote:
> On Fri, Feb 20, 2009 at 4:17 AM, Gordon Sim <gs...@redhat.com> 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!).
Well that reverses my opinion :) If only one style is allowed I think I prefer
the presence style. Where we have an args flag for the non-default state and no
flag for the default state. So that would be --no-auth to disable auth and in
config/env vars it would be no-auth=true or NO_AUTH=false. (no-auth=yes is odd
looking but not obligatory!)
That said I don't feel strongly. So if someone things its urgent to be
consistent let the start a vote, otherwise we can leave it where it is.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Alan Conway <ac...@redhat.com>.
Gordon Sim wrote:
> Rajith Attapattu wrote:
>> 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 .
>
> I think we intend to make every effort to keep the APIs backward
> compatible. There have indeed been changes that break this in the past,
> but they are not undertaken likely. Now we are out the incubator I think
> we will try even harder to avoid such changes.
>
> I accept there is a minor inconsistency in the broker options. I don't
> get the sense it's a big issue for most users though, and consequently
> I'm not convinced there is enough justification for the change.
+1
We are a released software product now, any change that would break an existing
users application needs to be carefully considered on its merits.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Alan Conway <ac...@redhat.com>.
Gordon Sim wrote:
> Rajith Attapattu wrote:
>> 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 .
>
> I think we intend to make every effort to keep the APIs backward
> compatible. There have indeed been changes that break this in the past,
> but they are not undertaken likely. Now we are out the incubator I think
> we will try even harder to avoid such changes.
>
> I accept there is a minor inconsistency in the broker options. I don't
> get the sense it's a big issue for most users though, and consequently
> I'm not convinced there is enough justification for the change.
+1
We are a released software product now, any change that would break an existing
users application needs to be carefully considered on its merits.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Gordon Sim <gs...@redhat.com>.
Rajith Attapattu wrote:
> 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 .
I think we intend to make every effort to keep the APIs backward
compatible. There have indeed been changes that break this in the past,
but they are not undertaken likely. Now we are out the incubator I think
we will try even harder to avoid such changes.
I accept there is a minor inconsistency in the broker options. I don't
get the sense it's a big issue for most users though, and consequently
I'm not convinced there is enough justification for the change.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Alan Conway <ac...@redhat.com>.
Rajith Attapattu wrote:
> On Fri, Feb 20, 2009 at 4:17 AM, Gordon Sim <gs...@redhat.com> 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!).
Well that reverses my opinion :) If only one style is allowed I think I prefer
the presence style. Where we have an args flag for the non-default state and no
flag for the default state. So that would be --no-auth to disable auth and in
config/env vars it would be no-auth=true or NO_AUTH=false. (no-auth=yes is odd
looking but not obligatory!)
That said I don't feel strongly. So if someone things its urgent to be
consistent let the start a vote, otherwise we can leave it where it is.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Gordon Sim <gs...@redhat.com>.
Rajith Attapattu wrote:
> 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 .
I think we intend to make every effort to keep the APIs backward
compatible. There have indeed been changes that break this in the past,
but they are not undertaken likely. Now we are out the incubator I think
we will try even harder to avoid such changes.
I accept there is a minor inconsistency in the broker options. I don't
get the sense it's a big issue for most users though, and consequently
I'm not convinced there is enough justification for the change.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Feb 20, 2009 at 4:17 AM, Gordon Sim <gs...@redhat.com> 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:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Rajith Attapattu <ra...@gmail.com>.
On Fri, Feb 20, 2009 at 4:17 AM, Gordon Sim <gs...@redhat.com> 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:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Gordon Sim <gs...@redhat.com>.
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:dev-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Gordon Sim <gs...@redhat.com>.
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:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Alan Conway <ac...@redhat.com>.
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:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Jonathan Robie <jo...@redhat.com>.
Gordon Sim wrote:
> Does anyone have a strong view on the desirability of making this more
> consistent?
Consistency really makes it easier to remember these things.
> 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.
Sometimes you think of a third possibility. I would rather change
--auth (yes | no)
to
--auth (yes | no | permissive | inherit)
than change:
--no-auth
to
--no-auth | --auth | --permissive-auth | --inherit-auth
So I prefer the "--keyword value" format for extensibility purposes.
> The next question is whether - if we do change these - we should also
> keep the original options for backward compatability?
Probably. Depends how much the users would squawk if we didn't. I'd much
rather clean it up and drop the old options if we can get away with it.
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: [c++] boolean options for qpidd
Posted by Alan Conway <ac...@redhat.com>.
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:dev-subscribe@qpid.apache.org