Re: sysinst split project - The Configuration File

[David Holland <dholland-current%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost