D-Conf

[Philip Van Hoof]

On Fri, 2005-03-04 at 10:40 -0500, Sean Middleditch wrote:


> Does this hypothetical configuration system REALLY need to be designed
> to handle early boot up or anything like that?  Is that perhaps just a
> tad bit of over-engineering for a DESKTOP configuration system?  Does
> early bootup even NEED a new configuration system?  Do the early bootup
> guys WANT a new configuration system?  The target of the new
> configuration system is desktop apps, so there's not a whole lot to gain
> by worrying but applications outside your target application set.

This is exactly what I initially tried to say about all this. I don't
think a configuration subsystem really needs to be designed to handle
system configuration nor early-boot-up anything configuration.

It just needs to handle the configuration of desktop applications and
perhaps some desktop-related major applications. Perhaps in time the
configuration of, for example, X.Org. But surely not the configuration
of your MTA nor of your Apache webserver or init.d scripts. Basically,
none of the files which are at this moment located in your /etc/.

> Does the configuration system really need multiple backends, instead of
> just writing one good one and leaving it at that?  Aside from a single
> fast, efficient, secure, safe local-storage mechanism and a single
> usable remote-storage mechanism, what other backends could you need?  I
> don't care about the geek factor; just because you can make a new
> backend doesn't mean you should.  If there isn't a very strong case for
> NEEDING to switch backends...  If you do need to switch backends, is it
> worth coding them up as dlopen'd libraries, or is the fact that you can
> swap in a different D-BUS daemon that uses the D-Conf service a good
> enough mechanism for changing "backends?"

No. It doesn't need multiple backends. GConf defaults to XML and this
works fine for 99.99% of the cases D-Conf would be used for. It's
impossible the achieve 100% compatibility with all possible cases in
this world. Any experienced developer will agree with that.

I don't think any deep integration with D-VFS is necessary. Perhaps it
could be useful to once create a D-VFS 'plugin' to handle D-Conf keys as
files on a filesystem. That way it wouldn't be necessary to write a
gconf-editor equivalent. I'm not sure, however, that the D-VFS API would
be suitable for using it as default way to get and store configuration
keys. I think that would be a to deep integration of both systems.




-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org