Re: sysinst split project - The Configuration File
David Holland <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.installation,gmane.os.netbsd.current |
|---|---|
| Message-ID | <[email protected]> |
On Tue, Dec 15, 2009 at 05:00:34PM -0500, Greg A. Woods wrote: > > 1. Most of the rest of this thread is conflating *configuration* and > > *scripting*. Configuration should not be Turing-complete, because it > > becomes unmanageable. (See "sendmail".) Scripting is Turing-complete > > by definition. > > I'm not so sure about that. > > For one I think your argument using Sendmail as an example is more or > less worthless. sendmail is only the most glaring example. > Sendmail configurations essentially describe a state machine -- and they > were not, at least when they gained their infamy, written in a truly > Turing Complete programming language. Oh? The Towers of Hanoi thing was just a joke? The basic reason configuration, which shouhld be data, should not be expressed in a Turing-complete way is that doing so makes it nearly impossible to write correctly-functioning configuration management tools. As in, you can have tools that select among canned configurations, but not tools that can interpret and edit an existing configuration. > > 3. Configuration should be done in a concise and legible format, > > such as key/value pairs, nested key/value pairs, columnar tables, or > > whatever. Since XML is content-free^W^W just syntax, > > Indeed, on both points! :-) > > > any such sane > > format can easily be represented as XML. > > Well, perhaps, but then you necessarily throw away the "legible format" > part again. Yes, but that's not the point; the point is that people who want XML for some reason can get it via an automatic conversion step. > > 4. Parsers are cheap. > > Sometimes they are not -- or rather there are scales of complexity and > overhead and other such costs in parsers, especially depending on the > language syntax they are intended to work with. Parsers for anything suitable for representing configuration data are cheap. For that matter, even parsers for sane programming languages are cheap. Parsing C++ is not cheap, but that's a whole different problem. > > If you have both configuration and scripting, the configuration data > > should be made available (as data, in a clearly defined schema) to the > > user scripts. > > Indeed. Typically in my experience this is easiest done, and perhaps > more importantly most effective, if the configuration language is the > same one as is used to define data structures and values in the > scripting language of choice, if at all possible. This is exactly the model I was arguing against. Or one of them, anyway. > But then I am very much a lisp fan. :-) no comment. -- David A. Holland [email protected]