[OpenAFS] Re: [OpenAFS-devel] Selecting a configuration file format for OpenAFS Services
Sat, 16 May 2009 17:27:16 +0200
thanks for a detailed answer.
On Sat, May 16, 2009 at 09:55:54AM -0400, Jeffrey Altman wrote:
> There are several problems with using the command line:
> 1. If all you are doing is setting a single value such as
> "rxmaxmtu=3D1200", that is conveniently represented on the command
> line. However, if you need to represent a complex data structure
> such as a multi-dimensional table using the command line is very
> user unfriendly and error prone.
Not really, unless you mean typing the command line. It may f.i. mean
having an option with a multiline value containing the table, in the
same way as it would be presented in a config file.
> 2. On some systems the length of the command line is limited in length.
> As a result it becomes impossible to configure everything via the
> command line. [On some systems that might be considered for
> future support there is no command line at all.]
Essentially what is interesting is not the so called command line but
the possibility to pass arguments to the main function. I think it is
easy to arrange on any platform by adding a wrapper main() which reads
a file containing the "command line" or a certain address in ROM/RAM
or you name it.
> 3. The usage model is different. With a command line all options
> that are specified must be understood or the application is supposed
> to fail. With a configuration file, the contents of the
> configuration are polled. Unrecognized options are silently
> ignored. This permits a single configuration file to be used
> with multiple versions / builds some of which might contain
> experimental features that are being tested.
With experimental versions it would be even safer and easy to use
separate config files (or command lines! :) , presenting different setups
to the different binaries.
If you mean that different programs need to share the same configuration
file, then it is a matter of tagging the contents, which can be trivial o=
highly complicated depending on the relations between different programs
This does not make "interfacing via program arguments" any less feasible.
> 4. Adding each and every configuration option to the command line
> is user unfriendly. There are literally hundreds of compile time
> values (most not configurable without a source code editor) that
> could be exposed for run time configuration. This would permit
> a wide range of values to be altered easily in order to tune the
> behavior of the AFS service to specific environments. Why should
> the absolute number of client hosts be hard coded to an arbitrary
> value picked in the early 90s? Why should the callback expiration
> behaviors (a complex table) be restricted to an arbitrary set?
Why is it "unfriendly" to have a possibility to specify an option via
command line? I would say giving the possibility _is_friendly_
and insisting on a config file _is_unfriendly_ at least in some situation=
If a certain option has to be multiline and follow some elaborated
syntax is fine - no worse than dealing with this in a configuration
file otherwise - which does not preclude using a configuration file
and reading it to the "command line" after all.
> This assumes that there is an external program that can be used to
> wrap. This assumption is not going to be valid in all environments.
Then the extra code would be necessary only for those environments
and given a suitable file format could be made trivial.
> > There will be also full backward compatibility with the existing
> > scripts and no need to modify the existing programs.
> There is no need for backward compatibility. We are not removing the
> existing command line options. We are also not ruling out adding
> new ones as they are appropriate.
> All of the OpenAFS services and clients already have configuration
> files with well-known locations.
Locations of config files in general tend to be in different places on
different platforms, different versions and distributions. Hardcoded
locations are especially painful as I must check that a certain program
does not unexpectedly import a configuration setting which I did not
This is one of the reasons why I am not especially fond of config files.
They tend to implement the sort of magic which works most of the time
but sometimes it does evil things.
> I believe I have given reasons why configuration files are a useful
I never contested the usefulness of a possibility to take configuration
from a file.
What I am advocating for is to allow installations to get by with command
line options only, if the corresponding user finds this appropriate.
My 2 =F6re have been said, going back into lurking mode.
Thanks Jeffrey and the mighty All for your work on OpenAFS.