Hi, Here is a post of mine from a past thread: http://mail.gnome.org/archives/gconf-list/2004-April/msg00024.html And what I would consider wrong with gconf: http://www.gnome.org/projects/gconf/plans.html Like all "grand unification scheme" efforts, without consulting and listening to the major customers, success is unlikely. e.g. when Keith P succeeded with fontconfig, he talked to and then contributed patches to GTK, Mozilla, Qt, etc. I would avoid lumping system config with per-user config. They are in some ways the same and in some ways very different. For per-user config one set of issues is around group policy, directory services, and that kind of sysadmin-creates-user-profiles issue; the other set of issues has to do with how the desktop is implemented and what UI we want, for example you need change notification. For system config the real issues of interest IMO are the overall management tools; things like cfengine, lcfg, oneSIS, or RHN. Another useful conceptual difference is between setting up a service/workload and associated data (e.g. configure apache, or stressing the analogy you could say that a user login session is a workload) and makework config such as telling the machine how to find its hardware (modprobe.conf type of stuff). The latter can/should be all automatic in an ideal world, though in a real world it can't be fully so. You might think of the makework config as adjusting all machines to be the same, and the service config as defining a service that can then run on any of the identical machines. User and system config can conceivably be addressed in the same library, as they share some core features, but I'm not convinced it has genuine value to keep them together. Anyway. This is certainly an area where work is useful, but I think it's a long road that involves both listening and coding in order to get wide adoption. Havoc
