Havoc's Blog

Evolution guys bringing up complex data structures again, here’s an
old mail on the subject. Check my “list of things I was planning
to get around to” in that mail, ah the follies of youth…

Storing “structs” (or dicts/hashes) as little XML strings could be a
totally sane underengineered solution, but surely needs some
convenience API around it, or perhaps standardize the XML format and
add a GCONF_TYPE_DICT_STRING rather than using GCONF_TYPE_STRING
ambiguously.

Increasingly clear that gconf needs a lot of work, notes here
for example. But I’m not sure how to get this done, I’m afraid that a
total
rewrite would just make different mistakes instead of
creating the Right Thing. Not that I’ve ever rewritten anything…

For the average admin, the primary mistakes in gconf (other than
multiple-login design bugs) seem to be things
that are confusing. Here are some of those and possible solutions.

1. The XML file format is confusing; the format itself is ugly,
the fact that it uses a filesystem hierarchy instead of a single file,
the starting filenames with “%” to avoid clash with key names, and the
historical lack of whitespace in the files… either a DB database or
a single huge XML file would have been less strange, though neither
would be as robust as the current setup, it would be more obvious how
things worked.

2. The fact that “schema objects” (GCONF_TYPE_SCHEMA) are “installed”
into the config database itself confuses the hell out of people; it
means there are two things called “schema” (.schemas files and
GCONF_TYPE_SCHEMA) and two things called “defaults” (the default in
the schema and the default in /etc/gconf/gconf.xml.defaults). Making
this worse, RPM spec files change one default and admins are supposed
to change the other default. Piling on to the confusion, schemas
aren’t exactly the same thing they are in LDAP terminology.

The solution I’d propose here is to yank schemas out of gconfd and the
config database entirely. Make them just XML files; apps load the ones
they care about at runtime and read the defaults themselves;
gconf-editor just loads them all. So have only .schemas files, not
.schemas in the database.

That does still leave people trying to edit the .schemas files to
change defaults, instead of changing gconf.xml.defaults. Not sure what
to do about that. Maybe it’s just not a problem.

3. Apps that have “profiles” add another layer of complexity that’s
sort of a pain in the ass. See gnome-terminal (or the panel which
has the complexity but not the user-visible profiles feature).

4. The panel has its own ad hoc complexity, as described here
and here.
I believe the panel could avoid this, by just copying the current
setup to new screens, or by creating a config source with ~/.gconf
removed and copying that. Or by using
gconf_engine_get_default_from_schema() or similar. Unfortunately
the panel is the number one thing any admin wants to configure, so
its extra complexity is most people’s impression of gconf itself.

5. gconf-editor doesn’t expose the right way of thinking about the
system, because it simply edits the current user’s
configuration. Ideally, we’d have a much more admin-task-based UI that
could do things such as “dump the current panel configuration to a
file”, “create a kickstart script to load said file”, or at least
“edit the systemwide default or mandatory settings.”

Anyhow… aside from all these gripes, the basic idea of gconf I
believe has been proven useful in practice. A process transparent
model-view approach to settings is the right architecture with genuine
advantages. But after a couple years remaining more or less unchanged,
some iteration and evolution towards a better implementation seems
long overdue.

One thing that has been fixed up recently is that the panel and
other apps in principle handle locked-down keys. Maybe it’s almost
reasonable these days to log in with ~/.gconf removed from one’s gconf
path, and start filing bugs about stuff that breaks…

Though that raises another topic, should frequently-changing transient
state such as current window positions be in gconf 😉 Consider an
LDAP backend, where LDAP is totally unscalable for writes and
reasonably scalable for reads. And of course this transient state
should get saved even on a fully locked-down desktop. So should
removing ~/.gconf even be counted as reasonable? The fuzzy split
between data, preferences, and transient state comes back to haunt us.

(This post was originally found at http://log.ometer.com/2004-03.html#1.2)