Re: Using XML to handle all configuration files
> Nicolás> I would say that each program would define its own tags,
> Nicolás> so in this example the namespace could be something
> Nicolás> like... http://www.debian.org/XML/etc/network/interfaces
> Nicolás> ). Similar programs should agree on a vocabulary, as they
> Nicolás> [should] do today with debconf variables.
>
> Agreed. Not sure if we should use www.debian.org (as some of this is
> configuration for upstream packages), but I guess this is a good start
> for now.
>
> You have shown one possible naming system. I will suggest another:
>
> http://packages.debian.org/heimdal-libs/0.3d-6/krb5.conf
>
> Where "heimdal-libs" is the name of the package, 0.3d-6 is the *first*
> version that uses this format (in case a latter version changes the
> format), and "packages.debian.org" clearly shows that this is an
> official Debian package.
Much better. But isn't it too soon to be discussing this? While every other
developer is thinking "what are these people talking about?"... =)
> Nicolás> Yes, a program edit the XML form of the config file, and
> Nicolás> the "xmldeconverter" writes the traditional format
> Nicolás> afterwards. Easy frontends can be created by the use of
> Nicolás> xpath, but without forcing debian developers to use xslt:
>
> Nicolás> conf="$(getconf "/interfaces/iface[@family='inet6']" )"
> Nicolás> test "$conf" && echo do you really want ipv6???? =)
>
> Nicolás> where getconf is a property getter program like the ones
> Nicolás> used by debconf.
>
> Yes, I didn't think of using XPath before...
It's perfect for the task, and it can be easy implemented by using the
libxml2 package.
> What you really need though (I think) is a corresponding setconf
> program, too. So a script can extract values from debconf and write
> them to the XML file for instance.
Yes, and these two programs would cover for the more simple uses (that will
probably be 80% of the cases). More complicated tasks would be done with
XSLT, or manipulating the DOM tree from perl, or python...
>>> 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.
>
> Nicolás> So.. each package would have a control file (like the
> Nicolás> ones in /var/lib/dpkg/info) describing the current
> Nicolás> conffile format version. This would be the "traditional"
> Nicolás> format, not the XML one. They XML one should not
>
> I am afraid you have lost me here, what is this extra control file
> used for?
Old package has in the control file:
/etc/network/interface 1.6
New one:
/etc/network/interface 1.8
Dpkg could go to a changelog and print entries 1.7 and 1.8. Isn't this what
you have proposed? But anyway, this doesn't seem to be related with XML...
> Agreed. Although this is something that will need to be tested in
> practise, too. For instance, it is possible that maintainers will make
> mistakes in designing the XML file which mean it has to be redone from
> scratch. It should be possible to provide assistance as required to
> people involved in designing XML files in order to minimise mistakes
> made.
Well, if this approach gets accepted, there surely be many issues to
overcome. This one in particular could be solved by changing namespaces and
making packages which want to change their internal configuration data format
(similar to change to using a diferent debconf variable hierarchy) create an
XSLT file to perform the conversion.
>> 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.
> Agreed.
It could be argued that the data doesn't really belong to a package, it
belongs to the user. And, from another package, the *user* might want to let
the package alter the config file.
The problem I see is with shared data. e.g.: Supose there are several web
browsers and each one have their own configuration files. Supose that they
doesn't understand http_proxy and that you want them to share that variable.
Should they share all their data in a common configuration data model for
browsers? Or some other mapping could be built on top of their own
configurations, like a config file saying:
Package 1:
XPATH: debconf style space:
/browser/network/proxy browsers/http_proxy
Package 2:
XPATH: debconf style space:
/browser/some-xml-node/proxy browsers/http_proxy
Reply to: