Re: XML vs. scheme for config files
the advantages of making config programs rather than files are that (a) they
can be easily parsed at runtime by merely evaluating the necessary forms,
giving one a powerful method of configuration, and (b) the problems of
static config formats forcing inconveniences upon you (for example: data
types are always a bitch) vanish. on the flip side of this, though, is that
the added complexity makes it nigh-impossible to write nice configuration
front-ends, and even if you can they will output comparatively unreadable
code (take a look at xemacs' customization menu for a warning). it might be
possible to combine the power of programmable configuration with the
convenience of administration front ends by writing templates for each
package, which have a list of variables to be entered as scheme expressions
and a template to turn them into nice code for editing, but then if you edit
the configs yourself you still make them incompatible with the
administration front end. i see two possible ways to deal with this:
1) have a two layer thing, along the lines of sendmail.mc; this sacrifices
run-time configurability for machine-readable configurations. you could even
get run-time configurability back on a per-variable basis by having a
special token which causes the configuration program to be run and that
particular variable to be re-evaluated. this still leaves you with a program
that can't be edited by the admintool, and gives you a headache with
synchronization (what happens when you update the program? easy, just rebuild
the configfile... but what if you edit the configfile directly? no way to
rebuild the program automatically), though.
2) have simple static data for most of the configuration, but allow a
special token to cause the value to be parsed at runtime, sacrificing
the front-end on a per-variable basis. you also lose the possibility to do
constructs that set more than one variable, or define separate utility
functions.
neither of these appeal to me very much; i guess we'll just have to live
with a choice between a pretty front end and ultimate configurability,
although it could at least be done on a per system basis (ie, have the
default settings be a program that the front end can parse, and then if you
want to program it you can go ahead and hack it up).
actually, to be perfectly honest, i think we could live with static
configuration data. there are not that many times when i wish i could write
something like httpd.conf or sendmail.cf in lisp. most of the times that
such things are used are in scripts which are programmable enough for my
purposes anyway. it would be cool to have dynamic configs, but i really
can't think of an example where it would be much more usefulo.
--phouchg
"For a price I'd do about anything, except pull the trigger: for that I'd
need a pretty good cause" -- Queensryche, "Revolution Calling"
PGP 5.0 key (0xE024447449) at http://cif.rochester.edu/~jpt/pubkey.txt
Reply to: