Re: gconfd errors w/nfs mounted homedirs
- From: Owen Taylor <otaylor redhat com>
- To: seth vidal <skvidal phy duke edu>
- Cc: Havoc Pennington <hp redhat com>, gnome-redhat-list gnome org
- Subject: Re: gconfd errors w/nfs mounted homedirs
- Date: Fri, 8 Feb 2002 23:36:13 -0500 (EST)
seth vidal <skvidal phy duke edu> writes:
> > One would think, but I haven't thought of it yet. ;-)
> >
> > Another possibility is to rely on the filesystem having change
> > notification, along the lines of FAM - but that's a big mess too.
> >
> > There's also the "just give up" approach: scope gconf per-machine,
> > include the hostname in the name of the config files, lock in /tmp,
> > and you have to reconfigure everything for each host. But this seems
> > pretty suboptimal.
> >
> > I'm very open to ideas on this.
>
> 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?
Well, basically because evolution, sawfish, and anything else that has
multiple things writing to the same config file without locking causes
corruption! There's no way I'd use two copies of evolution pointing
to the same directory at once.
You can usually get away with it in simple cases where configuration
is saved only when the user requests it explicitily, but once you have
complicatd situations, with lots of updates, things _will_ break.
If you are willing to give up change notification (and change
notification on config keys is proving to be one of the really cool
features of the GNOME-2.0 desktop), then you probably can get away
with a Berkeley DB style on disk database. But the gconfd approach is
a lot more flexible.
If you start talk about sharing configuration beyond a local cluster
of machines, then you probably would want to not make gconfd the
central configuration server, but use a configuration database like
ACAP and use multiple gconfd's There was some thought in the gconfd
design to allowing this, but it would probably wouldn't be a complete
drop-in to get it working.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]