<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.5.7"> </HEAD> <BODY> After reading most/all reactions I'm going to wrapup my first conclusions <H2> Whats needed </H2> A generic configuration system that will be used by most <B>desktop</B> applications. With desktop applications I mean that applications like GNOME and KDE applications could use it. But also applications like OpenOffice.org and Mozilla should have the ability to create a layer in their configuration-codings to utilise this generic configuration system.<BR> <BR> It needs to make it possible to "listen" for changes. Many applications want to reload specific parts of their configuration by handling such a "configuration key change" using a callback handler or callback function. In fact this is the default design for almost every current modern GNOME application. But not only that. Applications who are to be ported to platforms and system where it's not the default to have such a event-based configuration management, the system should also support a transactional API. So that you can "Apply" and "Undo" a series of settings.<BR> <BR> For many other minimum-requirements please read the other posts. Most of them are already implemented in the software "GConf". <H2> What isn't needed or perhaps needed but not in the scope of a project like D-Conf </H2> People have to understand that the "D" in D-Conf means "<B>D</B>esktop". Not "<B>D</B>ude this can do everything". It's a <B>D</B>esktop <B>Conf</B>iguration management system. It wont be started during the bootup of a computer system. It shouldn't be used for system services like a webserver or an MTA. It shouldn't be used to alter the tweak-settings of your kernel.<BR> <BR> There's perhaps a few exceptions on that rule. For example the project Eventually (please look it up) could read it's configuration from D-Conf. Eventually aims to provide a GConf-like replacement for the system services crontab and atd. Maybe in time this configuration-system could be used for <B>some</B> specific configuration details of the X.Org system. For example the per-user desktop resolution might be an interesting configuration key/value to store in a system like D-Conf.<BR> <BR> At this moment there's plenty systems and softwares available to convert existing system-application configurations into a database-with-triggers. There's no need to redo all this. Sure people need it. But it isn't the desktop application developers nor the desktop applications itself who are in need of it.<BR> <BR> Also, D-Conf wont magically make system configuration easer to manage. It will even put an extra needless layer on top of the current situation. Neither the system administrators nor the desktop users are in need of it nor want this.<BR> <BR> The configuration of your bootup is mostly in hands of the packagers and your distribution. In fact it shouldn't be alterable by a normal user at all. And for that single case "configuring which of the system-services are to be started upon startup" we shouldn't base an entire configuration management system on the possibility to do that. There easer ways to get that configurable by the user.<BR> <BR> <BR> <BR> <BR> <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> <PRE> -- 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 <A HREF="http://www.freax.be">http://www.freax.be</A>, <A HREF="http://www.freax.eu.org">http://www.freax.eu.org</A> </PRE> </TD> </TR> </TABLE> </BODY> </HTML>