Re: GConf design problems?

[Havoc Pennington <hp redhat com>]

Hongli Lai <hongli telekabel nl> writes: 
> I understand that GConf stores everything in an XML file.
> However, wouldn't that make things slower after a while?
> The more configuration is stored using GConf, the bigger
> the database gets.
> Does that mean that the database will get slower as time
> pass, because it gets more difficult to parse?

There is a separate XML file for each directory in GConf. For example,
the /apps/nautilus directory and /apps/galeon directory are a
different XML file.

So each XML file is small, containing only a few logically-related
settings.

Of course, XML is not always the ideal backend; that is why GConf
supports pluggable backends, so we can change the backend when
appropriate.

> And some people fear that the GConf database will corrupt
> just like the Windows registry.
> Or it may corrupt after a filesystem crash, they said.
> How big is the chance that something like this happens?

It depends on the backend. For the XML backend, this is basically
impossible; files are replaced atomically, a filesystem crash is
irrelevant. GConf handles out-of-disk-space gracefully. 

Moreover at most a single XML file would be corrupted (one directory
such as /apps/nautilus), and the others would be unaffected. So at
most you lose the prefs for one app.

Moreover losing GConf data does not hose the system; unlike Windows,
we are only storing preferences in there. So even if you get
corruption (which is not likely to happen), you at most lose some
preferences.

Moreover, it is stupid to say that GConf is more likely to be corrupt
than a text file, because GConf's default backend stores data in text
files. Moving the text file load/save code into an application instead
of GConf would not change how that code works; it would still be the
same. The fact that the code is in a library hardly affects things.

In fact GConf makes corruption less likely, because all applications
share a single, well-debugged, robust-against-errors load/save
codepath.

The current ~/.gnome/* text files do get corrupted from time to time,
by the way. Because they don't have any locking. Which is one problem
with using text files for configuration.

Saying that text files don't get corrupted is moronic; obviously these
people have never tried using LinuxConf. ;-)

However, this is all just implementation details of the current
backend. If someone wanted to write a backend that wrote out a huge
text file or a per-application text file to store data, they could do
that, and the text file could be in any format they wanted. The virtue
of GConf is an abstract API which allows us to plug in new formats
later.

The registry is not an abstract API in this sense, and it is also
importantly distinct from GConf in that it stores system configuration
and data, while GConf merely stores user preferences.

> I noticed that many people on Gnotices dislikes GConf.

I think it is mostly one moron who has also appeared on IRC a few
times. I think the points I've made above demonstrate that he's
utterly clueless.

> Some said that GConf makes their programs more unstable.

The majority of the bugs I know of that have caused noticeable user
problems have actually been CORBA/OAF issues.  I've now added various
OAF workarounds and I think if you have GConf 1.0.4 and have it set up
properly you won't see problems.

GConf sadly gets blamed for all these OAF issues because - gasp -
GConf bothers to report errors. So the dialog comes up "GConf: OAF
fucked up, file an OAF bug report" and everyone files a GConf bug
report. As Joel Spolsky says, users don't read dialogs. ;-)

Users have also thought GConf is unstable because it tends to log
error messages in syslog; most of these were provoked by
misconfiguration or buggy applications, but I've removed most of the
error messages in 1.0.4 because they worry people, and they can be
ignored. The messages have always been harmless, just logging "FYI,
some app did something silly"

In any case, GConf is an abstract API; so if OAF/CORBA continue to
cause issues we can easily just take them out. This is the purpose of
abstraction. I expect things to be working fine right now though.

Havoc