[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: sysinst split project - The Configuration File
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
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
> > 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. :-)
David A. Holland
Main Index |
Thread Index |