Re: proposed architecture evolutions for GConf

[Havoc Pennington <hp redhat com>]

Hi,

It's very simple:
http://www.gnome.org/projects/gconf/plans.html

We just need a volunteer to do those *three things* and a whole lot of 
pain would go away.

As a preface to responding to your mail, keep in mind that there are two 
interface points that need not use the same mechanism:

  user session on a host <-> some kind of global-to-network user state
  application <-> some kind of sessionwide state

Also, there are a couple of interesting cases. Traditionally, we've 
always thought about a LAN with user identities stored in NIS or 
something and user==UNIX-user. Each user has an NFS homedir.

However, another interesting case is an individual consumer with their 
data stored in a "cloud" (e.g. latest Google desktop stores its prefs 
somewhere in the Google cloud). So there's the local UNIX user then some 
remote account on the Internet.

Josselin Mouette wrote:
> I think a good short-term change is to revert to global locking by
> default. 

There is a way to turn on global locking again via environment variable, 
I believe. At least there used to be. So you could play around with it.

GConf was this way for the first several years. It is not a good idea, 
essentially because fcntl() locking over NFS does not work reliably in 
real production environments. (Not to mention people who insist on using 
AFS with hosts sharing a homedir that aren't even behind the same firewall.)

As you note, there are several problems with the per-user-and-host 
locking, but gconfd mysteriously refusing to start up at all due to the 
global locks resulted in loads of support issues and angry admins.

Regarding the three issues:
 - to fix notification of config changes to multiple hosts, you
   really must use a "central server" model (like IMAP).
   The only other thing you _might_ try is some firewall-hopping
   code like the P2P VOIP stuff - I think Google Talk's firewall-hopping
   library based on having an XMPP connection is open source.
   But just connecting from A to B with no fancy stuff is not
   going to work on many deployments, so just switching back to global
   locking won't help.
 - file corruption shouldn't happen; at least last I knew, the files are
   written atomically (all or nothing) by writing to a tmp file then
   rename(), so the possible corruption is that if you write
   both /foo/bar/baz and /foo//baz/bar both in two places,
   you might get one value from one place and one from the other.
   You will not get mangled XML or something like that.
   This should cause problems almost never in practice (especially
   since users aren't usually actively configuring the same thing
   on two hosts at one time)
 - the ORBit DOS applies to pretty much the whole desktop - I think
   ORBit may have some kind of code to counter this. It isn't
   huge in practice since you can look at who owns the offending
   file and apply real-world countermeasures such as disciplinary
   action, no?

> For a longer term, we can envision a new communication backend.
> Obviously, dbus comes to mind. Unfortunately, while it definitely brings
> some improvement for the single-host use, it is completely unsuitable
> for multiple host setups. And apart from dbus, I don't know of anything
> else that would give sufficient improvement over CORBA to justify the
> move.

What you want here is a gconf backend, not a replacement for gconfd.
You still want a per-session gconfd (which dbus is designed for) in 
order to cache the remote stuff and because it should default to local 
files to avoid mandatory configuration.

Then have a backend that uses either a central IMAP-like server, or adds 
some kind of P2P change notification to the file store.

I would encourage fixing the "3 things" from 
http://www.gnome.org/projects/gconf/plans.html first, because right now 
gconf backends are very hard to write and brokenly have to contain all 
the schema information.

> How about forgetting this communication thing? Configuration is stored
> in files, we just need to read and write these files. We even have some
> decent ways to monitor files now: local using inotify, remote using fam
> with dnotify.

It's harder than you might think because to do a gconf notification 
based on a file change, you need to "diff" the old and new config values 
in the file. Which means that either gconfd keeps all files loaded all 
the time, or that the backend puts only one value per file, or maybe 
another solution you can think of. One value per file will result in a 
_lot_ of files.

NFS fam, I think you'll find, is a disaster in practice that most admins 
will not get to work properly. Not sure it's even maintained, though I 
suppose it could be. Even if you get it sane on Linux you have a bunch 
of other platforms it won't work on, and AFS, etc.

If you meant to avoid a gconfd entirely and just have apps monitor the 
files, I would suggest that the per-session-daemon setup is semantically 
equivalent but a lot easier to code and much more efficient. You can 
share the file monitoring, local caching, and backend overhead among all 
the apps. Maybe most importantly you can share the overhead of reading 
in all the config when you log in among all the apps. It's also a lot 
easier to swap in a network backend using the per-session daemon.

One of the "would be nice" items on 
http://www.gnome.org/projects/gconf/plans.html is to remove "--direct" 
mode which is when the apps use the config backend directly, because it 
results in a much larger "libgconf" than just talking to a daemon does. 
With a dbus session daemon, "libgconf" would just be a maybe 50K 
convenience wrapper, and apps with an aversion to dependencies could 
just manually make the dbus calls and skip the lib.

Per-session-daemon also makes it much easier to have settings stored in 
a "cloud" for individual users without an IT admin, because the session 
daemon can log in to the "cloud" service and keep a local cache of what 
it finds there. It would be a mess if every app did this separately.

> If a migration
> script is provided, complete source and binary compatibility could be
> retained.

Something to keep in mind is that there's a need for both forward and 
backward compat with gconf, i.e. people often share a homedir among an 
older and a newer version of GNOME, both in active use.

You can accomplish this by completely renaming the storage (maybe move 
it to XDG_CONFIG_DIR) but that's the least-desirable approach since it 
means each GNOME version has to be separately configured. It would 
probably be worth it though if the config setup were really cleaned up 
nicely.

Havoc