Re: XML as a standard UNIX config file format (Re: Caldera installation - something Debian should learn)
>> "BE" == Bernd Eckenfels <lists@lina.inka.de> writes:
BE> On Sat, Apr 24, 1999 at 08:31:08PM +0200, Martin Bialasinski wrote:
BE> The Editor des not know about: Data-Types, Possible Values, Sematics,
Sure. Example:
When I edit HTML with XEmacs, and I am just inside a table tag, C-c C-e to
enter a tag will only list and allow valid tags inside of <table>.
If I have the point on the table tag and press C-c C-a to edit the
tag, I get
<table -- Edit values and finish with C-c C-c --
align = #DEFAULT
-- (left center right): #IMPLIED --
width = #DEFAULT
-- cdata: #IMPLIED --
border = 0
-- number: #IMPLIED --
cellspacing = #DEFAULT
-- number: #IMPLIED --
cellpadding = #DEFAULT
-- number: #IMPLIED --
>
BE> Support like: File/Color/Dont-Browser, does not know about the
BE> scope of a element (relative or absolte path), does not know the
BE> sematics of an element.
Sorry, I don't understand what you mean with this, I can just
guess. But I believe you want the Perfect Solution(tm). I don't know
if it is ever possible.
I call it the "Debian Syndrom". We want the technically best
solution. Sometimes this is not possible, so we don't do anything
about the mess, because the solution is only good enough in 90% of the
cases.
The pppconfig tool is not optimal. Still it is good enough to almost
quieten all questions about setting up ppp in Debian.
BE> All those problems you have both, with XML and other config files.
BE> XML is especially dump in this, there is no definition of allowed
BE> formats (date-field with YY-MM-DD) or allowed field lenghth. A DTD
BE> does not help in all of those aspects of config files.
We currently don't have these checks as well. A programm must check
its data anyway. And I don't see any _working_ format that does it.
BE> I love to write Markup Documents, I even use Word to write real
BE> markup. But this doesnt change the fact, that I dont see any
BE> support recent XML Editors will give me compared to
BE> Control-Centers like GNOME´s or KDE´s. Or even Linuxconf or
BE> .dot-file generator.
XML is a generic format. And one big diffenerce is, that we can have
support for it right now, as all language bindings are available. With
the generic format, we can prevent flamewars between KDE and GNOME,
X11 and console. Console is an important thing. Of cause you can edit
the files in $EDITOR, but you can also have an textmode xml editor. I
have yet to see such thing for GNOME or KDE.
xml is agnostic about your working environment.
You list four different config interfaces, and all of them only deal
with a small, often disjunkt part of configuration files.
The dot-file generator is a especially bad example. Any new module you
want to write has to clone the parsing interface of the application to
configure.
BE> I´m talking about parsing password files with thousands of
BE> entries. There is a good example, try runnng sendmail (as root) on
BE> a HP/UP Box with shadowed passwords and a few thousand passwd
BE> entries.
As someone already said, that you can easily create the native format
from a XML file.
>> I am sick of checking if I may use tab or not, what is the syntax for
>> config file xyz etc.
BE> I dont have problems with that. Well.. on the othe hand, I am used
BE> to work with it for years.
This is the point. Someone breathing 253 different config syntaxes may
not see any need in changing anything, but take the part time admin
like me or a newbie user who just wants to use the box with as few
fuzz as possible. I often kick something, when I install some new
programm and have to learn the quirks of
yet-another-config-syntax. This is an unneccesary thing. A standard
syntax makes it easier for a) the author b) the user c) a config
interface (control center , whatever you call it) writer.
Most of the Debian configscripts are only useful for the primary
configuration. Reading, parsing and using the previous values would be
a snap.
BE> It doesnt help if you dont know what tag is used for:
You don't have this info in the files now, so it has to be
added anyway. And it can easily be added into the file, and it is
automatically in a parseable form.
BE> old style:
BE> <direcetory /> rlimit=10000
BE> option indexes
BE> </directory />
BE> new style:
BE> <directory root="/"> <rlimit>10000</rlimit>
BE> <options>indexes</options/>
BE> </directory>
BE> Those 2 examples dont show me much benefit...
Ok, then add an example with fstab like syntax, one with bind8 like
syntax, one with syslod.conf syntax, one with login.defs syntax, one
with amd syntax etc.pp. and see the xml result. The xml version is
uniform. Once you understand the basics of xml, you understand any
config file, its structure and the conventions for values and
tags/options.
Ciao,
Martin
Reply to: