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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.