Re: gconfd errors w/nfs mounted homedirs

[Havoc Pennington <hp redhat com>]

seth vidal <skvidal phy duke edu> writes:
> 
> Why is what gconf is doing now such a great departure from what has been
> done in the past with config files? IE: if one of my users makes config
> changes from two sites it seems normal to believe that the last one to
> exit are the changes that get saved. Why is there a possibility of
> config file corruption in this situation and there isn't in evolution or
> sawfish or anything else? Why are galeon and nautilus special in this
> situation?
> 
> If it sounds like I am being a smart ass, I don't mean too, I honestly
> don't know.
> 

Here is an old but mostly still valid article:
  http://developer.gnome.org/feature/archive/gconf/gconf.html

One important feature is that multiple apps can use the same config
value. For example in GNOME 1 if I change whether menus have icons in
them, I have to restart all apps. In GNOME 2, all apps instantly
update. Which is kind of a cool parlor trick in that case (though it
does enhance usability), but then consider that Evolution and Nautilus
are actually made up of a number of processes, so they are effectively
multiple apps, and you see why it's kind of necessary.

Anyhow, the notification service is the main point of gconfd, with a
couple side effects (a global cache of the config files, and locking
for said files).

Owen makes a good point, that for real scalability we ultimately need
some kind of config server, ACAP is one design for that. GConf is
designed to let us plug that kind of thing in later as a replacement
backend.

I would expect the current implementation to work fine for the usual
NFS situation though.

The current architectural reason you need a single daemon is that it's
used to detect changes; so if you change a value it works like this:

  - app changes value by contacting gconfd
  - gconfd writes new value to storage backend
  - gconfd notifies interested apps of the change

To have multiple gconfd it needs to work like this:

  - app changes value by contacting gconfd
  - gconfd writes new value to storage backend
  - storage backend notifies gconfd that value has changed
  - gconfd notifies interested apps
 
At that point you can have multiple gconfd per user, since
notification of changes originates from the backend, not the
daemon. The problem though is that the backend has to know how to
_detect_ changes from any gconfd, and send them to the other gconfd.

This is really easy if the backend is another server, like an ACAP
server, and easy if we had a file change notification service like
FAM (but it would need to work over NFS/AFS).

Once it's possible to have multiple gconfd you can even just kill
gconfd, since apps can get the notify from the backend directly,
though there are arguments both ways on that.


Anyhow, I'm gradually working out the glitches (such as the timeout
length, the default ORBit settings, etc.) and also recently wrote a
little app that runs on login and does a sanity-check and gives you a
helpful dialog if things are hosed.

Havoc