Re: Feature proposals for GConf

[Colm Smyth <Colm Smyth ireland sun com>]

>To: Colm Smyth <Colm Smyth ireland sun com>
>Cc: gconf-list gnome org
>Subject: Re: Feature proposals for GConf
>From: Havoc Pennington <hp redhat com>

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

Of course.

>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

I brought up the subject of maps before in private e-mail back around May,
but I haven't had time to be able to put together a detailed proposal 
until now.

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

Storing gconf configuration data in GConf itself allows it to be more
easily managed in a multi-user networked environment.  There is no service
to allow access to the files /etc/gconf/*, but so long as a GConf backend
can reach the underlying data store (XML, BerkeleyDB or later LDAP,
relational database, etc), then you can update your GConf configuration.

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

My original idea was similar, but I believe that allowing the
client to have complete control of the configuration path is
simpler and more flexible. For comparison, here's the
syntax I had originally thought of:

option:arch=Intel xml:readonly:/net/workgroup/gconf/Intel

OR

option:arch xml:readwrite:/net/workgroup/gconf/$(arch)

With this mechanism, either gconf_init() or a new gconf_engine_()
API would accept a 'char **options' array similar to environment
variables (ie. each string looks like 'arch=Intel').

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

As I mentioned above, I believe that client-controlled configuration
path is simpler and more flexible than adding complex option
syntax to /etc/gconf/path. One example is that it would support
a sysadmin using a GConf editor GUI. I believe that a regular
end-user will want to see a unified key hierarchy which is
the view seen using the default GConfEngine. A sysadmin will
generally want to see multiple separate key roots, each
corresponding to a single-partition GConfEngine; however,
I bet that the sysadmin would also want to be able to
collapse the independent partition key hierarchies into
one so that he/she can easily see the end-result that
a given user or workgroup would see.

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

I believe we will have at least two GUI's - a native Gtk one, and
a web-based one (many adminstrators like browser-based admin tools,
especially if they provide secure remote access from a cybercafe
for example).

There are many other "meta-tools" that need similar flexibility from 
GConf:

- data "push" or replication tools (so that a sysadmin in a large
  organisation that has adopted GNOME can create a configuration
  centrally and then "push" config data out to GConf partitions
  on LANs worldwide)
  
- data "import" tools, that take data from another store (say an
  LDAP directory server) and merge it into a GConf partition

These tools could either work with an individual partition or
with a data-defined configuration path that will split keys
among multiple partitions using my proposed scoping/subsetting
mechanisms.  

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

There is a lot of power in GConf's ability to combine data from
multiple partitions into a unified key hierarchy that acts like
a single database.

In an enterprise environment, a sysadmin could split the GConf
partitions into logical settings:

- enterprise
- workgroup
- host
- user

It's also possible to split the partitions along environment or
device-specific dimensions:

- device architecture
- operating system
- preferred mail or calendar client

The subsetting and scoping mechanisms I'm proposing will allow
specific data to be obtained from a partition, and they also
allow key writes to be directed to specific partitions. If
the key structure has any directory element that corresponds to
some property that determines which partition can be used,
then keys can be directed to a partition very easily. For
example, in an environment where there are different OS's
or machine architectures, I want to be able to put specific
sets of GConf data into one or the other, for example:

/gnome/desktop/mime-config

(I made up this name, I don't know the key structure that
will be used for storing mime-type app/component bindings)

This key hierarchy will certainly identify executable components
that will be OS- and/or CPU architecture- specific, so I
want to ensure that it is separate from other configuration
data that is cross-platform.

I can do this using 2 of my proposals:

- the data-driven partition map allows a GConf client to select
  a set of partitions that match the current runtime environment
  (say I'm using Red Hat 6.2 Intel, so I want to use applications
  on a networked file-system that correspond to this)

- scoping to ensure that keys relating to the OS/architecture are
  obtained from (and written to) the correct GConf partition
  e.g.  xml:readonly:/net/workgroup/gconf/Intel should have a
       /gconf/scope directory that contains the 
       "/gnome/desktop/mime-config" key)

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

I don't think these issues will affect change notification. Transactions
are simply a "hint" that change notifications should go out together
and this is supported by my backend SPI proposal as it allows multiple
keys to be notified simultaneously. Making gconfd MT-aware (or at
least MT-safe) does require some changes, but they won't especially
affect change notification from the point of view of the backend - 
it just requires that the callback function that the backend will
call uses data-structures and ORBit in an MT-aware way).

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

I just see three real problems:

- it removes a point of concurrency control for backend partitions
  that are intended for use by a single user but that are accessed by 
  multiple GConf clients (e.g. the XML backend)

- it increases the load on each GConf client as they will each have
  GConf-internal data-structures and any backend-internal caches
  - would need to ensure that the gconfd code and the backends don't 
    create too much data
  
- makes function and data symbols for some internal API's visible to
  the GConf client (not a real problem as most/all global symbols
  have GConf-specific name prefixes and no GConf client should refer
  to GConf symbols outside of the public header files)
  
The advantages are:

- removes a single point-of-failure from the system (although gconfd
  will be re-started when a client makes a request)

- removes a performance bottleneck (no CORBA (de)serialisation and
  no IPC)

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

No, this would be bad - it would mean that backends have to each implement
the listener registration infrastructure and separately track
registrations.

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

See above for rationale.

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

The gconf_engine_new_with_address() does not use the subsetting
information that forms part of my proposed GConfAddress struct.
If it did, you could naturally just call it once for each address.

Colm.

>Havoc
>
>_______________________________________________
>gconf-list mailing list
>gconf-list gnome org
>http://mail.gnome.org/mailman/listinfo/gconf-list

--
Colm Smyth - Sun Microsystems, Ireland - Desktop S/W Engineering
Sun Xtn: 19166    Phone: 353-1-819-9166   Fax: 353-1-819-9200