Re: Feature proposals for GConf

[Havoc Pennington <hp redhat com>]

Hi,

This is all post-1.0 material of course due to the 1.0 release.

The principle I'd like to follow (an obvious one) is to make sure any
new features are motivated by concrete user/sysadmin needs we know to
exist; then address each need in the simplest possible way.

In general this set of features sounds about right. I'm not at all
done thinking about the issues though, so I have lots of questions to
get your thoughts on.

Colm Smyth <Colm Smyth ireland sun com> writes:
> 
> 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.
>

I've been calling a partition a 'source', though I tend to use
database sloppily to mean all sorts of stuff. ;-)
 
> 1. Configuration path definable as data in a GConf database
>

The last time I thought about this, I posted this mail:

 http://mail.gnome.org/archives/gconf-list/2000-September/msg00012.html

For the maps mentioned in that post, I was thinking we'd just have
/etc/gconf/map.defaults and /etc/gconf/map, or something along those
lines. Your idea is interesting though.

I haven't thought through all the issues yet; but I'd be interested to
hear your thoughts on the virtues of storing the map in the database
itself vs. in an /etc file, and also I think one of the main
considerations here is to be able to let an app say "this setting is
by default stored per-display" or whatever. So I'd like to have a very
clear idea how that feature will work in the design we settle on.

To get more concrete, roughly what I was thinking was:

<alias name="per_display" target="xml:readwrite:~/.gconf-per_display"/>
<alias name="default" target="xml:readwrite:~/.gconf-default/>
<alias name="workgroup" target="blah"/>
<mapping source="default" key="/"/>
<mapping source="per_display" key="/desktop/screen_width"/>
 
etc. Ignore the syntax, just trying to convey what info would be in
the map.

> 2. Client-controlled configuration path
> 
... 
> 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. 
> 

I'd feel a lot better about this if we had at least one concrete
example of a situation where a client would want to do this (assuming
we support getting a single source/partition as we do now). I'm
figuring that the intended client would be a GUI for sysadmins;
gconf_engine_new_with_address() is intended for that as well.

I guess my sense is, we try writing the GUI, if it needs these
functions we can add them. I don't want to add API just because it
could be useful someday with no concrete motivation. (Another option,
if it's only useful in our GUI, is to make it a private API in
gconf-internals.h).
 
> 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.
>

What's the motivation for storing the map information in two places? 
It seems to me that we'd need to collect the information from both
places and merge it somehow (presumably you'd take the union). Why
would a sysadmin or user choose to put the information in one place
over the other?
 
> 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.
> 

Clearly we need to do this, to make non-default databases work, and
avoid making all clients share a gconfd.

There are a couple issues that might affect its implementation
in significant ways though:
 - Transactions
 - Multithreaded gconfd

Or, if these don't affect notification too much, I'm guessing they'll
involve significant changes to how backends work. We need to do some
thinking about which of these features will go in GConf 2.0, how
they'll be implemented, how it all interacts, etc. I just got a book
on database implementation to get ideas on ways to implement
transactions, but I haven't read it yet.

On some level, if the backend can detect changes and we allow multiple
gconfd's, each process can just load the backends in-process, and we
drop the whole gconfd concept. It's worth thinking about anyway. I'm
not sure if it's worth doing. (There are many possible problems with
it.)
 
> 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.
> 

Why not just recycle GConfListeners in yet another layer; so gconfd
adds listeners to the backend, just as clients add listeners to
gconfd, and just as GConfClient keeps its local listeners tree.
 
> 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();
> 

I'd have the same concern I mentioned earlier, I'm wondering if any
clients actually have a use for this that would motivate dropping the
abstraction level of the API.

> 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's the value of this API vs. just calling
gconf_engine_new_with_address() N times to get N engines for N
addresses? You already have to write a loop to fill in your array of
GConfAddress, right?

Havoc