Status of gconf -> dconf

[seth vidal]

On Mon, 2009-02-23 at 17:17 -0500, Colin Walters wrote:
> 2009/2/23 Callum Lerwick <seg at haxxed.com>:
> >
> > What is this, Windows? Everything is a file. Hey, I have a wild idea!
> > Store your config in ~/.fooconfig/keyname, the contents being the value
> > of the key. Wow, now you have hashed key lookups, locking (fcntl),
> > change notification (inotify), permissions and ACLs...
> 
> This is the kind of design that makes kernel developers complain when
> they strace applications and notice how many system calls they take to
> start up.  Also, inotify has kernel limitations that would prevent us
> from using it on that kind of scale.
> 
> "Everything is a file" was a cute mantra for the 1970s, but reality is
> more complex than that.  As painful as it is, in general we've been
> moving more underlying storage in the desktop to mmap()able formats
> because it involves few system calls, doesn't take lots of file
> descriptors (not an unlimited resource), and works well in the
> multi-process architecture that for historical/political and some
> technical reasons we have.
> 
> Don't get me wrong - GConf has some very bad design flaws (at least
> should have used something like Protocol Buffers instead of XML), and
> I'm not defending the weird dconf licensing.

To be fair - a lot of the new mechanisms for storing config data don't
work with the filesystems commonly in use. NFSv3, AFS, cifs are 3 that
come to mind as NOT playing well with sqlite, in particular.

I think we need to be very careful in designing future config formats to
realize that the world is:
1. not a single user on a laptop/desktop
2. very commonly using shared filespaces - especially for homedirs

-sv