database map thoughts

[Havoc Pennington <hp redhat com>]

Hi,

I was just discussing the database map issue on IRC with George and
Owen, here are some notes from that.

We had previously decided to replace the path file with a more
sophisticated tree-shaped database map that allows sysadmins to
specify database paths on a per-directory or even per-key basis.

(Note that one implementation difficulty here is that right now we
have a hard time doing change notifications if multiple GConfDatabase
objects use the same database; but we need to solve this anyway, it's
already required by current GConf features. The solution is I think to
make all notifications emanate from the backend. But, that's a
tangent.)

The database map makes it theoretically possible to put any key in the
"correct" place (in a database designed to be per-display, per-user,
per-machine, per-workgroup, etc.)

There are a couple issues to address though. The first is that if you
define a given path as the per-workgroup path (say containing two
databases, an XML and an LDAP one, whatever), then you have to
cut-and-paste this path throughout the database map file. To address
this, the obvious solution is aliases for paths. So some way to say
"an alias 'workgroup' refers to the path 'xml:blah\nldap:foo\n'".

The second issue is that we need to ship a default GNOME setup that 
works properly out of the box on a standalone workstation. This means
that applications need to provide some hint for each of their config
keys or directories whether those keys or directories should be
per-display, etc.

Some examples: the GNOME panel configuration should likely be
associated with a particular X display, because it depends on
resolution; the recent documents menu should likely be
per-home-directory, since your documents are likely in your home
directory. So we want to somehow do this by default.

A suggested solution is to define some conventional database aliases,
such as "display", "home_directory", etc. and have applications
install the suggested default database alias with each key or
directory, perhaps list these in the .schemas file.

The suggested default database can't actually be stored in the schema, 
since the schema is in the database. So we would need a "defaults map"
in addition to the regular database map, and when installing the
.schemas file we'd stuff things in the defaults map.

On startup, gconfd would assemble its map of which databases to use
for which keys by first parsing the default database suggestions map,
then overriding the defaults with whatever the sysadmin has in the
main database map file.

It's simple to override all defaults by defining the database for "/"
in the database map.

I'm not sure how the database map or the default database suggestions 
would be stored on disk; the main database map is probably a single
XML-style file, the defaults may need to be more scalable than that.

We need some way to support user overrides for this, comparable to the 
way ~/.gconf/path gets included right now. Requires some thought.

We need to assemble a list of conventional database aliases that make
sense for a single-user workstation.

So that's my brain dump on the outcome of my most recent conversation
on the issue...

Havoc