config-aware widgets (was: Re: Experiences with KDE-CVS at LinuxWorldExpo)

[Havoc Pennington]

On Mon, Nov 11, 2002 at 08:29:36PM +0100, Tim Jansen wrote:
> My current 'solution' is to reload the configuration every 60s in all 
> processes and check whether there were any changes. The part is quite 
> complicated and error-prone.
> 

Right, this is exactly the problem gconf's "process transparent"
feature is intended to solve.

> You could solve the problem by creating a kded module that controls all access 
> to configuration files. Applications can register with the kded module when 
> they are interested in a configuration file. Before a KConfig instance writes 
> the file, it must 'lock' the configuration file by sending a DCOP message to 
> the kded module. The call blocks when another application is currently 
> holding a lock. The kded module will then load the configuration itself and 
> tell the KConfig to go on. Then the KConfig can modify the configuration 
> file. If it is finished, it sends an 'unlock' DCOP message to the kded 
> module. The kded module will compare the old configuration with the new 
> configuration and sends notifications about the changes to all processes that 
> are interested in the configuration file.

A "file lock server" is IMO less efficient and flexible than a
complete config server, though no doubt easier to get running. One
loss of flexibility is (obviously) that you're limited to config files
only in this case.

> This can, BTW, also be used to allow transactions on configuration files. The 
> app must then lock the configuration file manually, reload it, modify it and 
> unlock it. For krfb it could be useful, because it is possible (even if 
> unlikely) that several processes modify the config file at the same time.

It can't be used for finer-grained or cross-file transactions though
(i.e. it limits the scope of a transaction to "things in the same
file"). Perhaps worth it, but the tradeoff is there.

To me *if* KDE is going to go down the road of wanting configuration
optionally on a central server (meaning LDAP etc.) or down the road of
"process transparent" configuration with change notifications, it
makes a ton of sense to unify on a gconf-style solution IMHO, rather
than a lot of ad hoc extensions to the .ini files, or a
designed-from-scratch solution.

Anyway, I'm just throwing the idea out there. Certainly don't assume
gconf is immutable, I'm happy to rename it, remove dependencies, etc.
Or basically happy to throw out most of the gconf implementation, as
long as the semantics are such that I can keep the current gconf
client API working with different internals.

It'd be pretty darn nice if linux/unix had a standard API in this
area.

Havoc