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: > > 1. If all you are doing is setting a single value such as > "rxmaxmtu=1200", 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 or 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 situations. 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. 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 öre have been said, going back into lurking mode. Thanks Jeffrey and the mighty All for your work on OpenAFS. Regards, Rune _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
