On Sun, May 02, 2004 at 11:53:16PM +0200, Alain.Frisch@... wrote:
> On Sun, 2 May 2004, Bardur Arantsson wrote:
> > I was just looking through my myriad of files in /etc, and
> > you know what...
> > I could only find *ONE* configuration file that used a
> > hierarchical structure. That must mean something...
> We should define what we call hierarchical. For me, a .ini file has a flat
> but still hierarchical organization. In the exim config file, you have
> sections (ended by the keyword "end", and some items in sections are
> compound items, with several key-value bindings). This is already a
> two-level hierarchy. Similarly, the XF86Config file has sections and
You're right; it's useless to debate something without
defining things properly...
But just for the record: It was a poor choice of words of
my part. I actually meant it in the sense of "structurally
recursive", i.e. something which can be nested arbitrarily
deeply and still make sense -- for anything else, I think
(blatant opinion follows! :)) that .ini is superior to
Btw, good call on XF86Config (xorg.conf in my case), the
single file I found was something else (can't remember
what it was now). Even so, that file is not structurally
recursive, it just has sections and subsections; AFAIK it
doesn't have subsubsections (or any other structure which
can be nested arbitrarily deeply).
> > > An XML syntax could be:
> > >
> > > <sshd_config
> > > port="22"
> > > hostkey="/etc/ssh_host_key"
> > > ...
> > > />
> > >
> > > Is it really that complex ?
> > It's _unneeded_ complexity that I have a problem with. Not
> > coplexity per se.
> So: has the example above unneeded complexity ?
Yes, there is markup which is not needed -- if the
structure is flat, there is no reason to have an
"sshd_config" element. It's implied.
> > If you changed the sshd_config like you suggested, then
> > you would now need to list all possible settings twice:
> > Once in the DTD and in the actual code which parses the
> > file. That's just bad software engineering practice...
> I'm not necessarily advocating the use of DTD. With .ini,
> you won't have any formal description of the validity
> constraints either.
True, but that is beside the point: With .ini you are at
least not artificially separating the validation into two
parts: Structural validation and semantic validation. It
might sound like a good idea to separate them, but in
practice the structural soundness and semantic soundness
are actually so tightly linked that it doesn't actually
make sense to separate them.
The trouble is that people assume that structural
soundness = semantic soundness and so assume that
everything will suddenly and magically become easier when
using XML. This is also why "interchanging" XML is not
really as easy as XML proponents like to make it sound.
Sure, you can tell if it's syntactically valid, but you
have no way of knowing whether it's semantically valid.
> > MTAs: Exim uses it's own format and thank $DEITY for that.
> > It's simple and to the point -- In fact I'd go so far as
> > to call it beatiful (at least relative to all other mail
> > servers I've tried).
> If exim.conf, sections are just closed by the "end" keyword. They have no
> name. So you can find:
> Go figure out in which section you are.
The same applies to any XML document where an element can
</ol> <--- which list is this??
When I want to find a section I usually also start by
searching for the section name -- My guess is that that is
what any reasonable person would do.
> From my exim.conf:
> # This file is divided into several parts, all but the last of which are
> # terminated by a line containing the word "end". The parts must appear
> # in the correct order, and all must be present (even if some of them are
> # in fact empty). Blank lines, and lines starting with # are ignored.
> I wouldn't call this beautiful.
Beaty is of course entirely subjective, but I actually
like it... Then again, I also like LISP. :)
> > Web server: Apache doesn't use XML. Yes, it's
> > hierarchical, but their parser can actually distinguish
> > between when something is supposed to be an int and not a
> > string (wihtout having to do a second pass as it were).
> > The reason that it's hierarchical is NOT virtual hosts --
> > they cannot be nested, but the recursive nature of
> > permissions on DIRECTORIES. So there.
> <IfModule> directives can also be nested. And as I said, there can be
> hierarchy without recursion (and this is the case).
Yes, again I meant "structurally recursive". Sorry for not
being clear about that.
I'm actually not sure that <IfModule> is actually
required. It might have been better if the Configuration
parser just emitted a warning on unknown settings/sections
and otherwise ignored them. As an aside, IMNSHO one of the
best examples of how to implement this sort of format
extensibility is the chunk naming convention of PNG -- of
course it would be slightly different syntactically, but
it would do away with having to use the IfModule
> > ml-donkey: No idea about this one...
> ml-donkey uses the Options module which was also released in Cameleon.
> The API may be worth a look:
> What about using the syntax of OCaml values for config files:
> port = 22;
> protocol = [2; 1];
> host_keys = [ "/etc/ssh/ssh_host_key";
> "/etc/ssh/ssh_host_rsa_key" ];
> keep_alive = false
That actually looks reasonably sane, but I sort of feel
that you're burdoning the user needlessly by having them
specify the types of the various settings...
Remember: Just because something is a string does not
necessarily mean that it is a file name or that said file
exists, so the library's user (ie. the app programmer)
always has to double check anyway. If the program checks
anyways, why should the user have to specify what type of
data they are entering? Of course, the user has to know
that some particular configuration setting takes string
values (simply because they have to know the semantics of
the setting the they're changing), but they shouldn't have
to *specify* the types redundantly.
Such "type specification" may be necessary for
disambiguating the input, of course, but that cannot be
avoided in some cases (just consider a filename containing
a "," in the following example).
port = 22
protocol = 2, 1
host_keys = /etc/ssh/..., /etc/ssh/...
keep_alive = false
protocol = 2
This format would require less of the user and would still
be perfectly computer-parsable. In fact, I might be
tempted to implement something like this if I weren't so
busy right now...
Btw, I'm not saying that .ini is the be-all and end-all of
configuration file formats, but I *am* saying that it's
better than XML for almost any *practical*
(configuration-format!) situation you can think of. If
there's one thing I've learned through all those years at
university it's that you should always, always, always
optimize for the common case (i.e. is a simple
non-recursive configuration format), but still make the
uncommon cases _possible_ (which they actually are with
I still don't think we've heard any convincing arguments
A computer lets you make more mistakes faster than any other
invention, with the possible exceptions of handguns and Tequila.