gconf brain death (was Re: [linux-elitists] Yet another mozilla atrocity)

Martin Pool mbp@samba.org
Wed Oct 1 17:08:44 PDT 2003


On  2 Oct 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> on Wed, Oct 01, 2003 at 12:51:16PM -0700, Nick Moffitt (nick@zork.net) wrote:
> > begin  Peter Whysall  quotation:
> > > Here's a little bit of my metacity config, reformatted:
> > > 
> > > <gconf>
> > > 	<entry name="num_workspaces" mtime="1064845100" muser="pwhysall"
> > > type="int" value="1"/>
> > > 	<entry name="theme" mtime="1064845279" muser="pwhysall"
> > >  type="string">
> > >  		<stringvalue>Industrial</stringvalue>
> > > 	</entry>
> > > </gconf>
> > > 
> > > Not exactly opaque, is it?
> > 
> > 	So each time you edit that in vi, you've gotta run "date +%s"
> > and throw that in the mtime attribute?

You're not meant to edit it in vi, except in extreme circumstances.
Databases that are human-readable but not intended to be edited
directly are OK.

Here is a case that is handled poorly by other configuration systems,
but that gconf handles well.  It explains why it has mtimes.

In earlier versions of Gnome, you could change the colors and fonts of
the terminal from a menu.  Each program had its own text configuration
file.  The changes are written every time the option is changed, and
read at startup.  This is pretty standard and traditional for Unix
programs that allow interactive configuration.  Presumably this is
what Karsten and Nick prefer, assuming they don't want to prohibit
interactive configuration altogether as being too microsofty.

It's not uncommon for people to use more than one terminal.  If I
change the color in one terminal, the file is written.  Other
processes are not affected.  Whichever one writes the file last wins,
so you can end up with some changes being lost.  (Yes, you could want
several different types of terminal, but that's not the point here.)

gconf fixes this by notifying every process when something changes,
and reconciling updates from various processes.  A reasonable and sane
way to do this is with a daemon that manages the files and serves
clients.  Other systems are possible, such as holding locks on the
configuration file and polling its mtime, but I don't think they're
any better.

-- 
Martin 



More information about the linux-elitists mailing list