xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Morrison <d...@es.co.nz>
Subject Re: XML for linux config?
Date Fri, 10 Dec 1999 21:07:57 GMT
Yes, well sort of.

I've been looking into this myself slightly for a while.

Sounds like a move in the right direction, but as we see there's a lot
more to it than just making a decision to do it that way...

>Why not store all the config information for a computer in one XML file?

Nooo. As the objections to the registry point out - it leads to
artifacts. And my objection is it gets too big & slow too fast.

HOWEVER if you can impliment a linking scheme that _refers_to_ further
XML app-specific config files ... thats more like it. 

The app configs should have a syntax to override global settings -
rather than changing the defaults... although that could lead to
confusion when trying to see where that actual value is set... hmmm

The "a single repository for configurations" is a fine thing. One of my
first moves on a new install is to alias all (and only) the config files
I want to one conf directory from which I access them forever. I'm sure
someone can come up with a stylistic reason why this is a Bad Thing -
but it works for me. This is not the same as /etc for several reasons.

Other BIG difficulties as noted by stefano
>This might work well for Apache as a whole, 
> but I don't think anyone has the power to 
> impose something like that on Linux or any other OS.

.. is it's NEVER going to be supported fully by all possible apps, so it
can never be regarded as 'the one view' on a system.

This leads us to having to regard the XML conf file as an abstraction of
the real configuration file ... which leads us to the problems of
synchonising the representations - until an app goes "100% pure XML" as
per the Apache 2 suggestion.

6 lines of perl could probably handle keeping an ini style file in synch
with a parallal XML file, but it only just starts there.

This abstraction is a pain... but it should DEFINATELY not prevent you
from using that abstraction in your own developments. I've been moving
in that direction for a long time.

THEN there's the entirely unique problem of conf file formats. Not only
do many have their own syntax, many even include logic - which cannot
&&/|| should not be represented in XML. 
Includes MAY be possible, but (eg.) my install of linuxconf barfs on
ifModule ... as (I presume) 'if' logic is (appropriately) out of the
scope of the linuxconf parser. Forgive me, I haven't delved its depths,
I just use it occasionally :-).

And a a final thought, I REALLY wouldn't want to see a file format that
precludes or even obscures the glory of inline comments! As a neophyte I
disregarded the famous 
# Do NOT simply read the instructions in here without understanding
# what they do.
admonitions happily for many months until I really had to look further. 
Succinct comments are worth the world, and I'd appreciate if any move
towards conf.xml went out of its way to ensure full, non-destructive,
round-trip comment parsing AND rendering.

That's my pure opinions on this matter, somewhat overlapping with
Stefanos good points.


View raw message