Re: XML as a standard UNIX config file format (Re: Caldera installation - something Debian should learn)
On Sat, Apr 24, 1999 at 07:35:54PM +0200, Bernd Eckenfels wrote:
> On Fri, Apr 23, 1999 at 02:57:07PM -0000, Robert Woodcock wrote:
> > UNIX *badly* needs a common config file format, and we might as well start
> > now.
> Why? The config formats of the different unix config files is used because
> different application needs different information structures.
I strongly doubt the sentence you just wrote is the real reason you are
asking why.
There is no practical reason why every piece of UNIX configuration can't be
put into a hierarchial tree with its own unique namespace. [1]
If you disagree, please come up with an example.
> > And, I daresay, sendmail.cf could be XML'd rather simply.
>
> Hu? What is the difference between a Tag <myname> and a tag M: if you enter
> both with a config program?
Nothing. That's why we should pick the most flexible and expandable config
file format, not necessarily the easiest one to parse.
> An XML PArser is very heavy wighted and I dont see a Reason for it.
It's overweight if you have each program implement it all over again, as is
currently done. It's not overweight as a dynamically linked library that's
done right.
[1]
I believe this is the real reason you think every application needs a
different information structure.
Up until now, every program has had to implement a config file themselves,
instead of using a common access method.
String parsing is the bane of programming - especially C programming. Most
coders don't go home at night and say to themselves, "That was a really cool
string parser I wrote today." (or go to work in the morning and say that
about last night - whatever :) Instead, they say "I'm glad I finally got
that string parser working well enough." Programmers attempt to define all
the fields they'll need, and try to fit the config file format around it,
taking as many shortcuts as possible. That's why we have things like
/etc/passwd ("noone will need to store phone numbers in here!"), /etc/hosts,
/etc/conf.modules, and fvwm[2]rc. All different formats that would fit into a
hierarchial structure very well (especially fvwm[2]rc).
> Each config file will still have different strucutres and tag names which you
> have to learn.
Those structures and tag names are *documentation*.
> Personally I prefer a /etc/hosts with 3 columns over an XML
> file with a lot of nesed tags I cant work on with grep or shell tools.
Unexpandable config file formats like /etc/hosts are one of the reasons we
should be looking towards an XML or bind8-style format. Something that can
have fields added on easily, in a backwards compatible manner. This requires
tags to be identified. I don't see any other way to achieve that goal -
fixed-table config formats and their associated undocumented grafted-on
manglings simply must die.
You wanna use grep or sed or cut or awk or whatever on your config
information? Go ahead. Just use it on the output of the shell
configuration utility and then pipe it right back in through the same config
utility.
It's not really any different from the same dpkg --{get,set}-selections
stuff you do now (for example), just more flexible.
--
Robert Woodcock - rcw@debian.org
"Now we'll have to kill you." -- Linus Torvalds
Reply to: