On Sun, 17 Feb 2002, Keith Packard wrote:
>
> Around 10 o'clock on Feb 17, Andrew C Aitchison wrote:
>
> <moving a discussion from devel to xpert about XML configuration files>
>
> > Can I at least ask that changing to an XML format config file
> > requires a major version increment, to version 5.0 if it happens now ?
>
> Sure, any change to the configuration file syntax will need to be well
> advertised and planned far in advance. A transition strategy will be
> needed.
>
> Having just experienced the real horror of a non-standard configuration
> file format, I will argue strongly that XML is a better solution than any
> custom configuration file format. Even for people editing the file with
> emacs.
>
> We are barraged weekly with questions about how to specify various
> configuration options in the config file. Yesterday, someone asked
> why the following failed:
>
> Option "ZAxisMapping" 4 5
I had the exact same questions and solved it with
Option "ZAxisMapping" "4 5"
I am very strongly against XML configuration files.. XML is really rather
poor for hand editing so it is best written by another program. If you are
going to have another program write the file anyway you can just as well
use the current syntax, it is no worse.
>
> I doubt fully half of this list's readership could solve this problem; it
> wasn't immediately obvious to me.
>
> It's not that the current syntax is bad, it's just different from
> everything else, as any custom configuration file sytax is. Moving to XML
> solves this problem -- the syntax is now regularized so questions about
> quoting and such won't occur.
And plenty of other questions will occur.
>
> Automated tools are another problem; with the current syntax, comments
> inserted by the user will probably be lost when the file is read and
> rewritten by an external configuration tool. This means that you can
I say that's a poorly written configuration program, I do not see it as
too hard to retain the comments.
> either edit the file only by hand, or only with a GUI tool. Libxml
> preserves comments and formatting so that reading/writing the
> configuration file won't make it impossible to edit the file in the future
> with a text editor.
>
> Finally, using XML means that external tools needn't worry about additions
> to the configuration file syntax or contents -- the file is always
> parsable, and the configuration tool can simply ignore portions it doesn't
> understand without any question of whether the remaining portions of the
> file will be misunderstood.
Do you really want a tool that does not understand complete syntax of the
configuration file (let alone semantics) messing with Xserver
configuration ?
>
> I had this particular problem with the Xft configuration file.
> Configuring fonts is of critical importance in a desktop environment. Xft
> provides a new level of customizability, and KDE wanted to expose that to
> the user. To get at the configuration file, they incorporated the Xft
> parser into their own code; they had little choice; there was no other way
> to extract the semantic meaning of even a portion of the file. This
> means that KDE can edit *one version* of the Xft configuration file, but
> any changes will break that support.
>
> I clearly needed to provide programmatic support for parsing the
> configuration file and regenerating it. I could have developed my own such
> mechanism, but I decided to try a different path -- using standard
> existing tools that already solved this problem.
>
> The results were very encouraging; I switched from a custom parser to XML
> in a day, developing a DTD and writing the tree-walking code was
> straightforward and also illuminated a few dark corners of the
> configuration file semantics. I also got to delete lots of code, which is
> always a good feeling. The resulting parser is more robust against
> failure and the file can be verified by external tools before attempting
> to install it in the system. This latter result would be very nice for
> XFree86 configuration files -- instead of starting the X server to
> discover a configuration file syntax problem, you'd run an external tool
> to verify the file, catching and fixing any errors found quickly.
Not everything is a tree. Good that it works for you - it could also work
in a number of other ways.
If there _is_ a need for extending configuration file (despite the fact
that the trend was to reduce its size and contents) may I humbly suggest
something line based ? And if you really want to make a monster of it, why
not tie XFree86 into Tcl and make XF86Config a Tcl script ? This would
allow for a number of fancy things like, for example, autodetecting
configuration at startup without mess of C code.
Vladimir Dergachev
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
