Re: GConf Backing Locking

[Havoc Pennington <hp redhat com>]

On Fri, 2004-02-13 at 06:55, Ghee Teo wrote:
>     How does gconfd gurantee atomic write currently?
> 

Write file to a temporary name then rename()

(Also addresses out of disk space and other errors)

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

Local locks require multiple daemons to access the same backend, but of
course the daemons can create inconsistent saved settings. With global
locks the backend is still locked.

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

Almost anything works really. If we used dbus for local gconf, we may as
well use it for the remote server. But even something as simple as
XML-RPC would probably work fine. Or LDAP for that matter.

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

I think there's no more question of key conflict with two sessions than
with two apps in the same session.

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

Or periodically.

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

See the paper I wrote for OLS; probably you need to keep a local copy of
everything that can be synced/merged with the server.

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

It's basically reasonable, but it's a big job and requires a lot of
care.

Havoc