Re: config system thoughts

[sopwith redhat com (Elliot Lee)]

On 20 Jul 1999 18:46:53 -0400, Havoc Pennington <hp@redhat.com> wrote:

>Any comments on this? It's a bit of a work in progress. Not sure if I'm
>going to code it or not yet.
>
>
>GConf design notes
>==================
>
>Data Types
>===
>
>Must be able to store int, float, string.

We need string vectors.

I think going into more complex data structures is really overboard.
Putting that functionality outside GConf (e.g. have a gnome-dentry routine
for reading dentries, and perhaps providing decent GConf hooks to make
this easy) will help make GConf be simpler and more robust.

>Namespace
>===
>
>Is a fully hierarchical namespace (filesystem-style) really required?

Yes.

>I think no. If you have simply two levels, a per-vendor and
>per-application namespace, plus lists/records, I think that's
>fine. And it reduces the complexity of backend implementations and the
>API quite a bit.
>
>So every actual key-value pair would be stored under
>/vendor/appname/key. Remember that values can be "records," giving you the
>equivalent of a "section" in gnome-config.
>
>Most existing applications with roll-your-own config solutions have a
>basically flat namespace like this. gnome-config does too.
>So there's little evidence that the hierarchical space is useful IMO.

How many existing uses of gnome_config have you looked at? I just did a
'tree -d ~/.gnome' and got three directories deep, and that's ignoring the
two levels that individual files and sections within files add.

>Config Sources
>===
>
>A config source is something like a URL. It has two parts: a "protocol"
>(backend), such as Berkeley DB, flat text file, Oracle, LDAP; and an
>"address", which is a backend-specific string sufficient to locate the
>particular config source. Could be a hostname, filename, directory
>name, whatever makes sense.
>
>Each config source can respond to queries for any /vendor/appname/key
>values, if only with "no value set."
>
>Sources can be read-only or read-write with respect to a given user. 
>If a config value is taken from a read-only source, then applications
>will need to desensitize the widgets used to modify that value.

(This paragraph seems rather irrelevant - what the app does is its
problem. In many cases the layering will mean that the value just gets
saved to one of the read-write sources in the config path.)

>Source Layering
>===
>
>Config sources can be layered in a search path. For example, you might
>configure your GConf to first check your user settings stored in flat
>files in ~/.gconf, then the systemwide Berkeley DB in /etc/gconf, then
>the network-wide LDAP configuration.

We also need to be able to define path aliases of sorts - e.g.
	systemwide/ -> /etc/gnome/
	per-user/ -> ~/.gnome/
	per-display/ -> ~/.gnome-`hostname`-$DISPLAY/

>Notifier/Listener architecture
>===
>
>Apps should be able to register themselves as listeners for a given
>section of the namespace, to be notified whenever a config value in
>that namespace changes.

Do you have some examples of where this would be needed? This adds more
complexity and is almost a sidetrack from the main purpose.

>Locking
>===
>
>Obviously the backends should have locking so multiple apps can edit
>the same key if needed.

Definitely, and this time around, no half-baked jobs ;-)

>Key Metadata
>===
>
>Each key must be explicitly registered with the GConf system; on
>registration, a short and long description of the key's purpose should
>be stored. Also the key's type. It will then be an error to store the
>wrong type in that key. The description can be used in generic config
>tree browser/editor applications.

. How are you going to handle trees that have runtime-generated section
names in them? E.g. the panel stores each session
	
. I hope the requirement is not actually enforced on the programmatic
level, even though it is a good idea. Making stuff inflexible is the road
to a hated API ;-)

>Metadata will also include the time of the last change, and an
>arbitrary string identifying the software or person who made the
>change. Packages (deb/rpm) can use this to decide whether a key has
>been modified since the package was installed. (Is this necessary? We
>could simply say that the source layer installed by the package is
>never modified, instead administrators would add an additional layer
>overriding it.)

>Command line tool
>===
>
>A nice command line tool will be written to allow shell scripts to
>access config information. This is important for postinstalls and the
>like.

We already have this, BTW - see $prefix/bin/gconfigger :)

>gnome-config should remain unchanged for backward compatibility and
>stability; apps would gradually migrate to the new GConf API. I don't
>think it's feasible to implement gnome-config in terms of this more
>powerful system without breaking the more powerful system.

Ugh, this sounds sort of sucky. While obviously the first priority is
getting the new API working period, it shouldn't be hard to redo
gnome_config in terms of the new API...

I would also be interested in hearing how GNOME performance and memory
usage will be improved (bloat is not an option! :) by switching from
gnome-config to GConf.

-- Elliot