Re: Using XML to handle all configuration files
> 1. user can edit XML file in such a way that changes will be preserved
> across upgrades and reconfiguration with dpkg-reconfigure[1]. Scripts
> that need to modify given settings can easily modify the settings
> without accidently messing around with other parts of the file
> (eg. comments).
The same settings in both files? How would them be synchronized?
> 2. long term goal: programs can start using the XML format directly
> rather then have the intermediate step. This would enable to
> programmer to focus on improving the program rather then questions
> like "is my configuration file format really flexible enough to allow
> me to add feature XYZ?" (I know I have had problems like this in the
> past).
True. And Debian would be helping upstream authors to adopt the XML
technology in their configuration files.
> <debian/> contains information specific to Debian which upstream don't
> consider there problem, eg. parameters required for daemons, etc.
> Debian scripts could use this directly, I don't see any point
> in using a non-XML file here. Of course, existing settings
> need to be extracted from any existing files, but I imagine this
> should be easy.
I wouldn't separate items by source, I would separate them by intent.
Perhaps a <distribution-integration/> tag for things related with how the
package interacts with the rest of the system.
> <redhat/> other distributions could also include distribution
> specific stuff as required.
Ah.. you want a way to make a setting valid in a system and not in another,
but this should be done with every setting, probably including upstream
ones. Perhaps an attribute <sometag valid-on-distro="debian >= 2.1"> would
be more appropiate.
> (perhaps these two could be merged into one - that is open
> to discussion).
>
> <update/> would be used by an intelligent config editor that
> can restart and update files as required.
Yes, that's nice. In this tag there would be the actions to take to commit
the changes.
> <upstream/> the interesting stuff, which would get converted to the
> traditional config format.
Uhm... I don't know... this should be a per-tag thing.
What I extract from all this is that you say that there would be more data
in the xml version than in the traditional version. So the one-to-one
mapping would not be posible. Another way to handle this is to allow to have
several files that 1) their tags would be processed as if they were in the
same tag 2) one file would use xinclude to include the other...
> (actually I code take this one step further, and make the file generic
> so it will work on any computer, even if /etc is NFS shared, but lets
> keep to the KISS principle for now).
Yep.
I've started to code something, I'll say when I have something to show...
Reply to: