Hello Jeffrey, On Sat, May 16, 2009 at 12:33:07AM -0400, Jeffrey Altman wrote: > The gatekeepers are opposed to the addition of new compile time > options because it puts packagers in the position of determining what > features administrators and end users are able to deploy without > building from source.
Right. > However, additional command-line parameters have > their own complexity issues. For example, the current fileserver > command line has approximate forty options; many of which are no longer > optional for reasonable deployment configurations. > There are several proposals on the table for additional features that > require new configuration capabilities. I believe that it is time that > OpenAFS adopt a configuration file format and library. A separate configuratrion file is not the best solution for all cases or for all administrators. Nevertheless it can be useful. In my eyes a separate file containing the necessary configuration settings as command line arguments is no worse than a different syntax, without imposing a need for extra efforts. I would suggest to rely on a separate program to process a config file with the syntax of your choice and produce command line options to give to the binaries. I suggest at the same time to deliberately make the syntax nearly identical to the command line options one. Then the parsing program will be trivial -- like "grep -v '^#'" -- and there will be no learning threshold for maintaining the configuration in its "config file" form. There will be also full backward compatibility with the existing scripts and no need to modify the existing programs. Rationale: Going for a configuration file, you would need to either hardcode its location (and probably choose different locations depending on the platform-specific packaging, thus adding to the confusion of the admins) and/or add a command line option to point out the file, which essentially adds to the number of files to be taken care of: 1. the script starting the services must set this option to point to 2. another file which sets more options. This can be expressed in two mostly equivalent ways: A. <binary> -config <configfile> B. OPTIONS=`cat <configfile>` && <binary> $OPTIONS The second way does not need any new support in the <binary> nor introduction of a new configuration syntax. With other words, choosing the configuration file syntax to be like -<option> <value> ... -<option> <value> ... ... gives you all the power wihout any modifications of the software nor in the documentation. In practice though I would do OPTIONS=`grep -v '^#' <configfile>` to allow comments in the file, which is quite useful. [As an example of an unfortunate switch to "configuration files" I would name stunnel. Version 3 is very convenient when you generate options on the fly, which is quite painful with version 4. Creation and cleanup of temporary config files on demand is burdensome ans sometimes impossible, f.i. if you do not have a writable file system at hand. OpenAFS is hardly being used with volatile configurations but the general point remains, an introduction of an explicit "config file syntax" gives no direct advantage per se and postulates some efforts both in development, learning and deployment.] My 2 öre Rune _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info