[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Using XML to handle all configuration files



>     Nicolás> <interfaces> <comment>This is a comment</comment>
>     Nicolás> <auto>lo</auto> <auto>inet</auto> <auto>loopback</auto>
> 
>     Nicolás> <iface name="lo" family="inet" method="loopback"/>
> 
>     Nicolás> <iface name="eth0" family="inet" method="static">
>     Nicolás> <address>10.1.2.2</address> <network>10.1.0.0</network>
>     Nicolás> <netmask>255.255.0.0</netmask>
>     Nicolás> <broadcast>10.1.255.255</broadcast>
>     Nicolás> <gateway>10.1.2.254</gateway> </iface>
> 
>     Nicolás> </interfaces>
> 
> I have sent this to you privately so not to confuse issues on
> debian-devel (I think some people are still nervous about the whole
> idea). So feel free to repost any of this if you want.

 True. People feels nervous when hearing XML. They don't realize that things
are actually simpler, as much of the code is available *now* (have you used
libxml2? It's very easy... ).

> 
> I would try to have some standard for all config files, eg
> 
> <config>
>   <interfaces>
>   ...
>   </interfaces>
>   <update>
>     <xslt ...>
>     <restart execute="/etc/init.d/daemon reload" uid="root">
>   </update>
> </config>
> 
> (not sure how this would actually look, and it would require XML
> schema, not DTDs; nor have I tried to use namespaces properly)

 I would say that each program would define its own tags, so in this example
the namespace could be something like...
http://www.debian.org/XML/etc/network/interfaces ). Similar programs should
agree on a vocabulary, as they [should] do today with debconf variables.

> So, a program that edits the config file just needs to lookup the
> update section to see what should be done when the config file is
> updated (eg run XSLT conversion, restart daemon, etc).
> 
> The <interfaces>...</interfaces> section mirrors what you have
> exactly.

 Yes, a program edit the XML form of the config file, and the
"xmldeconverter" writes the traditional format afterwards. Easy frontends
can be created by the use of xpath, but without forcing debian developers to
use xslt:

conf="$(getconf "/interfaces/iface[@family='inet6']" )"
test "$conf" &&	echo do you really want ipv6????
=)

where getconf is a property getter program like the ones used by debconf.

> Other things could be useful to, eg, changelog describing when and
> what changes where made to this config file, etc.
> 
> I think some of these features would be very useful, and may even
> stronger arguments as to why XML files are required then what has
> already been discussed.

 So.. each package would have a control file (like the ones in
/var/lib/dpkg/info) describing the current conffile format version. This
would be the "traditional" format, not the XML one. They XML one should not
change.... hey..!!! here is a big thing::!!! imagine that the traditional
format changes, so on package replacement, the configfile is converted to
XML by the old package, and converted to "traditional form" by the new one.
So we have an automatic migration procedure free...!


> I would almost be willing to argue that packages may edit XML config
> files from other packages (currently against debian policy), because
> this is much more flexible then anything that could be specified on
> the command line for an update program. Care needs to be taken though,
> as the XML format could change... Perhaps a compromise between the two
> extremes might be good (eg. update program which takes XML as its
> input).

 Besides, with XML, the editions would be something cleaner than the current
"sed" approach. Editing other packages files is probably forbidden in part
due to the fragility of this method.
 Perhaps it should be mandated how should programs which modifies other
programs file should behave. Like prompting to the user or so. 

> Comments?

 Some.. =)

 I'm posting this to debian-devel, but in a new thread. I think there are
interesting things that should be "researched"...



Reply to: