Re: [system-tools]xml configuration file / (libsysconfig?)

[Juan Luis Baptiste <juancho phreaker net>]

Hi,

>
> This is an interesting discussion from a distro point of view too, however
> I agree that it wouldn't be easily realizable. Keeping configurationitems
> duplicated would only lead to problems, however I do think GST could
> provide a (better/more useful) interface for providing a unified
> configuration backend, which would in turn make it easier for others to
> make different UI's for configuration tools, and add new backends
> separately.
>
> Currently, the backends are very useful but also reasonably focussed on
> GST.
> Retrieving configuration information is done by directly calling a perl
> script which dumps a xml file to stdout (correct me if I'm wrong, I'm
> fairly new to GST). Configuration can be set my giving each script the
> --set option and the new configuration xml on stdin.
>

I don't agree. I don't think the backends aren't very GST oriented as I use 
the network backend in a tool for KDE called KNetworkConf 
(http://knetworkconf.sf.net). The backends don't have any kind of dependency 
with the whole GST package nor with GNOME. I just copied the perl scripts I 
needed to get the network backend working and that was all. In fact, Carlos 
Garnacho is thinking in splitting GST into separate packages (frontends and 
backends), as he once told me in IRC. The XML format is pretty standard to 
me, I don't see what could make it very GST oriented.

> As stated, the backends are fairly GST specific. There is no single
> interface/API to connect with, there aren't any DTD/Relax NG schemas for
> the configuration files. From what I can see, there isn't a way to check
> which configuration backends are registered for a platform, without testing
> them all. In short, it's more a bunch of scripts than a unified backend
> detached from GST. I'm putting it very blunt, I know you guys have been
> putting in a huge effort, and it will work well for GST, but imho there is
> a long way to go before GST's second goal (unified system configuration)
> succeeds. Then again, nobody ever said it would be easy! :)
>
Well, you can run ./[backend] -d platforms to know wich platforms are 
supported for a given backend (ie. ./network-conf -d platforms will list all 
the platforms where the network backend con run in). What you can't do as I 
have seen, is to run a command that will tell you wich backends are available 
and to wich platforms, but you can easily acomplish this by running all the 
*-conf scripts (the backends) with the -d platform parameter.


> What am I thinking of? A C API for compiling frontends against, using
> libxml2 and (at least in the beginning) the current backend scripts, with
> one simple commandline tool for retrieving and setting configuration info
> using xml. Extra configuration libraries could register (a la pkg-config)
> with this library by providing a list of supported platforms and the name
> (+ schema?) of the new configuration backend. Configuration clients could
> easily (via the API or cli) check which backends and if the necessary
> backend exists, retrieve the version of the schema (or the schema itself)
> and get/set the configuration items like the separate scripts now. Voila :)
>
I don't know about this one. I think is adding more complexity to something 
that already works fine and it's very simple to use. I'm a big fan of the 
KISS philosophy (Keep It Simple Stupid!, no ofence ;-) ), and I don't see 
which benefit could bring a C API to GST, if you currently can do everything 
you want with the XML files.

> Naturally, a single configuration interface is still far off. But GST, as I
> see it, is the most flexible and would be able to bring together distros
> (and wm's) if this is done properly. Until that time, getting more and more
> configuration tools to use the backend would slowly bring this goal closer.
>

Agreeded on this one :-).

Cheers,
--
Juan Luis Baptiste
http://www.merlinux.org
http://knetworkconf.sf.net