[OpenAFS-devel] Selecting a configuration file format for OpenAFS Services

[u+openafsdev-t07O@chalmers.se]

Hello Jeffrey,

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:
>=20
> 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=
r
highly complicated depending on the relations between different programs
and options.
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=
s.

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.
>=20
> 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.

Good.

> 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
intend...

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
> addition.

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.

Regards,
Rune