Re: per-display, per-session, etc. settings

[Colm Smyth <Colm Smyth Sun COM>]

GConf schemas provide documentation that can be used directly by the
configuration API; very useful with a general purpose graphical configuration
editor, specially for administrators.

Sym-linking databases into the key namespace at a particular key
root is a useful feature, which we thought of (over a year ago?)
but haven't yet implemented. It's a useful mechanism for dynamically
composing configuration information.

Havoc actually didn't accurately describe what the partition map does,
but it will make more sense when the code is integrated (soon).

Colm.

>Delivered-To: gnome-components-list gnome org
>From: Dietmar Maurer <dietmar ximian com>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Havoc Pennington <hp redhat com>
>Cc: gnomecc-list gnome org, gconf-list gnome org, 
"gnome-components-list gnome org" <gnome-components-list gnome org>
>Subject: Re: per-display, per-session, etc. settings
>
>Havoc Pennington wrote:
>
>> Hi,
>>
>> I'm not sure how they relate, but the profiles etc. stuff was
>> previously planned for GConf in a slightly different way.
>>
>> Here is an early writeup:
>>  http://mail.gnome.org/archives/gconf-list/2000-September/msg00012.html
>>
>> There was some later discussion, and Colm implemented the idea of a
>> "partition map," and the plan changed somewhat.
>>
>> But basically we specify per-key or per-directory
>> (e.g. /desktop/background/*) whether a setting is per-session
>> per-display etc. Colm has already implemented the idea of "partitions"
>> which lets you do that.
>>
>> What's missing is a way to put a hint about which partition to use in
>> your schema file, and then setting up the default GConf path to
>> contain partitions for these various uses (per-display etc.)
>
>I still don't know why we need the idea of "partitions", or "schemas". We
>can extend the bonobo-config interface slightly and it would be able to
>handle all those things:
>
>void addDatabase (in ConfigDatabase default_db, in string path, in DBFlags 
flags)
>
>Where flags is READ, WRITE or MANDATORY. This enables us to mount/link
>another database somewhere inside the tree. You can also easily create a
>sub-database from a existing database, representing a subtree. This
>enables you to make virtual links inside a database, for example you can
>make "/desktop/ " such a virtual link, pointing to another location inside
>the database "/somewhere/else/host.name.com:0.0/"
>
>My view of things is that there is one system database, which stores the
>default values and the documentation, located somewhere in /usr/share
>(just an example, may be configurable). IMO there is no need for schemas,
>so it is just like any other database. They layout of my databases would
>be something like  this:
>
>/path/to/a/value  - a normal value (a value in the system database is a
>default value)
>/docs/                 - this subdir contains the documentation
>/display/             - virtual link used to mount display specific
>settings
>/session/             - virtual link used to store session specific stuff
>
>The second database is the user database inside the user home directory.
>The default configuration database is then simply a combination of those
>databases. Please notice that you can combine databases in a quite complex
>manner, just using the above addDatabase() function. A simple, but very
>powerful mechanism.
>
>- Dietmar
>
>
>
>
>
>