Re: GConf Backing Locking

[Ghee Teo <Ghee Teo Sun COM>]

Havoc Pennington wrote:

> Because gconfd writes are already atomic (you won't get half of one
> daemon's file and half of another's), 
   How does gconfd gurantee atomic write currently?

> locking "as needed" I don't think
> adds anything; you could as easily not lock at all and have an
> equivalent situation. In fact GCONF_LOCAL_LOCKS=1 (the GNOME 2.4
> default) is an equivalent situation. Only GNOME 2.2 still locks that IOR
> file AFAIK.
   Yeah. In the HEAD, I see gconfd is now default to local lock :)
What I also see that the xml backend write is no longer locked, what has 
changed
since the change over of default to LOCAL Locks that we don't need a 
lock when
writing to the backend?

> What isn't addressed by this is the problem of inconsistent database
> state; i.e. panel in login session A writes half its settings and panel
> in login session B writes half its settings. That is the hard problem to
> solve, and one clean solution is to support a gconf server used by both
> login sessions, as discussed in my OLS paper from a couple of years ago.
   Thanks. I understand this is the crush of the problem much better. 
The basic
problem boils down to having multiple gconfd which may have changed values,
One possible solution is to have a single backend daemon that merges
all the changed gconf keys over a secure connection.

The daemon would do
- this daemon is per user across multiple machines
 What communications protocol do we have to achieve this may be the big
  question here.

- receive a key change from a gconfd and update its cache
 So key values is maintained up to date.

- broadcast the changed key to all the gconfd for that user
 Since it is unlikely that the user can be at two sessions changing the 
key at the same time,
 the question of key conflict is never arised, unless the account is 
used by someone esle :)

- save its cache to disk when the last gconfd connection closes

How does one handle off-line configuration changes? Presumbly off-line 
mode user has
the home directory on a local disk of the laptop, one can use the 
include $HOME/.gconf.path
to load in the configured value to be merged in with each other.

Does these sound reasonable or am I just pushing the problem further 
back :) ?

-Ghee