An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Thu, 2005-04-07 at 22:13 +0200, Philip Van Hoof wrote:
> On Thu, 2005-04-07 at 16:02 -0400, Avery Pennarun wrote:
> 
> > In a config system, the problem comes down to this: nobody wants an
> > "asynchronous get" command in their config system, because it turns simple
> > things like "what colour should I make this widget" into a multi-line
> > callback/state machine nightmare.  But if you're querying the network, you
> > have to be asynchronous, because it could take an undefined amount of time
> > for the answer to come back, and you can't afford to freeze your app in the
> > meantime.  Threads don't help, because *all* the threads want to know things
> > about the configuration.
> 
> No no no no :). You misunderstood the text. Every desktop will run AND
> cache it's own configuration system. Only for pushing new configuration
> data will network transparency be used. Some keys, therefor, aren't
> writable. It basically means that the original location HAS to be an
> authorized source (like another daemon, or like an ACAP-server).

ps. So yes. This means that initializing a new user (starting the
conductor for the first time while a network source is identified in the
local (small) configuration (/etc/dconf), basically means getting all
those default (and unwritable) keys from that network source, and
filling the backend with those defaults (from the configuration server).

Also, resetting such a backend basically means removing the backend-
data-files (the SQLite files) and restarting the conductor (the daemon).

etcetera


-- 
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