Feature proposals for GConf

[Colm Smyth <Colm Smyth ireland sun com>]

Hi,

I'd like to propose some new features for GConf.  I use the term 'partition'
below to mean a portion of a GConf database identified by an element of the
GConf configuration path, e.g. xml:readwrite:$(HOME)/.gconf is a GConf
partition, while a GConf database is the entire database seen by a client
application and it is defined by the entire contents of /etc/gconf/path.

The features are:

1. Configuration path definable as data in a GConf database
2. Client-controlled configuration path
3. Partition map, scoping and sub-setting
4. Backend SPI change - support change-notification
5. API change - new API's to get/set the configuration path, along with the
   new information provided by partition scoping and subsetting.

1. Configuration path definable as data in a GConf database

Currently the entire configuration path is defined by the file
/etc/gconf/path.  This feature allows a GConf partitiion to include other
partitions in the configuration path.

One way to achieve this would be to specify that "/gconf" is a directory for
configuration information relating to GConf itself and that the values of all
keys in /gconf/partition/ identify other partitions to be included in the
configuration path.

For example, If /etc/gconf/path lists partitions a, b and c, but partition b
references sub-partitions b1 and b2, the effective configuration path is a, b,
b1, b2, c.

2. Client-controlled configuration path

As already mentioned, the configuration path is defined by the file
/etc/gconf/path. However, there is little value in attempting to
enforce a specific configuration on GConf clients as a well-behaved
application will use the configuration information in the path
as defined, while a badly behaved application will simply not
use GConf to control it's logic.

Some applications may wish to be able to use the ability of GConf
to work with a set of GConf database partitions, but may need
to tweak the configuration path slightly.

Permitting a client to get the default configuration path and
modify it before creating the default GConfEngine would enable
this. 

3. Partition map, scoping and sub-setting

GConf currently searches linearly through each backend partition in the
configuration path until a key is found, both when reading and writing values.
This affects performance, but it also means that there is no way to direct
keys to be written to specific partitions.

The solution proposed is to allow each partition to identify the base
directories of all keys in that partition.  No key should be stored or
requested from this partition unless the key is 'within' or 'below' a base
directory.  This list of base directories is associated with each partition in
the partition map (the partition map is simply the configuration path
augmented with this set of base-directories).  This does not eliminate linear
search, but it ensures that some partitions will not be requested for some
keys, effectively allowing searches to be directed to specific partitions.

There are two mechanisms proposed:

- scoping
- sub-setting

Scoping puts the list of base directories into the partition, perhaps in a
new GConf key directory /gconf/scope.

Sub-setting puts the list with the configuration path element; that is it
lists the base directories alongside the address of the partition, e.g.

xml:readonly:/net/configuration/gconf /gconf /gnome/desktop/mime-config

ensures that all GConf clients sharing this configuration path will
neither read or write keys unless they are in one of the directories
/gconf or /gnome/desktop/mime-config.

4. Backend SPI change - support change-notification

Currently a gconfd process sends notifications for changes to keys that it
processes, however if another client updates a backend store via another
gconfd process instance, there is no way for the backend to request gconfd to
send change notifications.

The solution is to extend the backend SPI to allow backends to trigger change 
notifications. One issue is that changes should not be notified twice, once by 
the backend and once by gconfd.

Ths SPI needs to allow gconfd to register a change_notification callback; it 
could look like :

gboolean (*register_change_notifier)(void (*cb)(GSList *changes))

where changes is the list of names of keys that have changed.  The return
value is TRUE if this backend supports change notification.  If the return
value is FALSE, gconfd should take responsibility for sending change
notifications for any changes made to that partition in that gconfd process.

I suggest that the callback is registered for each partition and not simply
for each backend to allow for the possibility that a backend has different
capabiliities in different circumstances (e.g.  the backend is a wrapper for
multiple database types each of which has different capabilities, or the
backend can provide notification for database partitions on the same host but
not remotely).

5. API change - new API's to get the configuration path, along with the
   new information provided by partition scoping and subsetting.

This API could look like:

	GSList *gconf_get_addresses();

where the list returned contains GConfAddress items. A GConfAddress looks 
like:

struct GConfAddress {
	gchar *address;
	GSList *directories;	/* the *scope* or set of allowed directory
	                           names for all operations involving a key
	                           on this 'database' */
	GConfEngine *engine;	/* the engine for this address */
}

This list of addresses may be passed to the API

gboolean gconf_engine_new_with_addresses(GConfAddress *addresses,
int n, GConfError *error);

The address and directories memberse of each address is specified when
calling, and the engine field of each address is initialised on
return from the API. For consistency, the list of addresses could
be provided as a GSList (though this makes the use of the API less
clear).

What do you think? ;)

Colm.