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

[Dietmar Maurer <dietmar ximian com>]

Colm Smyth wrote:

> 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.

I know, but my approach also contains this documentation (we are talking about
implementation details here).

> 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).

Please can you describe that.

> 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
> >
> >
> >
> >
> >
> >