Neil Schneider wrote: > James G. Sack (jim) wrote: > >> Whatever you end up with, I strongly urge minimizing structure, >> especially nesting. >> >> I think the good-ol' ini file format has a LOT of headroom. >> And sections containing tuples map nicely into hashes/dictionaries. >> >> I believe there is a lot of good published code to deal with ini file >> reading and writing. > > I like the methods that are used in Postfix. If a line starts with > white space, it's a continuation of the previous line. Commas separate > multi-values on the right side of equality. Default values are > included and commented in the configuration file, so most of the > important values are exposed. If you want to see all the values, > including those not set you can run a command, postconf to see the > values as set. This makes it easier to see them, without the comments > inside the config file. You could do a lot worse, IMNSHO than using a > postfix config file as a model. >
If you're talking about files that may need to be (perhaps only infrequently) maintained by ungeeks, it might be worth trying to _avoid_ some of the conveniences appreciated by specialists. Problematic features: a) continuation lines (or somewhat different: multiline data) b) data lists I don't have a good suggestion for a) other than try to avoid the need. Admittedly, if variable names are required to be tokens, then the absence of \s*<leading token>\s*= may be easy enough to explain and recognize as continuation data. For b), I think multiple "assignment" tuples might be easy to explain understand (and fairly easy to program). Using _any_ kind of separator to define a list raises questions of either choosing a separator that will not occur in the data, or inventing an escaping/delimiting mechanism. Of course, I admit I've assumed things about \n <heh>. Having a utility that can parse and report the conf data is certainly nice, and could be the basis of a UI. In any case there's always a question of whether to allow human-friendly variables or to require names that programs permit for symbolic labels. I would vote for imposing the latter constraint -- it's not hard to explain, it not too hard for users to tolerate, and it probably avoids a great source of subtle bugs. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
