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 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.
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
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.
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.
> Sorry, are you suggesting that we include libxml2 code, or that
> we use the one in the system ? I'd certainly prefer that we use
> one installed by the system when available. For distributions with it,
> can we recommend that it the user install it rather than using a
> version we provide.
Yes, the intent is to use the one provided by the system, but as libxml2
isn't widely available yet, XFree86 includes the source for systems that
don't provide it, just as we provide source for things like the regex
library and FreeType.
> Is it a new policy that XFree86 should only support "reasonable"
> systems ? It used to be a matter of pride that it ran on a wide
> range of platforms.
No, the question is only how to support existing platforms while still
providing new features. The case in question involves a system with
optional support for a standard library function (iconv); we can easily
support that system by requiring that the optional library be loaded for
XFree86 to function. I'd include source for that library, but the license
is incompatible with our source distribution, and it's not the only
implementation.
Keith Packard XFree86 Core Team Compaq Cambridge Research Lab
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
