[Colm Smyth <Colm.Smyth@ireland.sun.com>] Re: GConf

[Havoc Pennington <hp redhat com>]

---

• From: Colm Smyth <Colm Smyth ireland sun com>
• To: Colm Smyth ireland sun com, robert odea ireland sun com, john heard sun com, hp redhat com
• Subject: Re: GConf
• Date: Mon, 21 Aug 2000 16:52:53 +0100 (BST)

Hi Havoc,

Nice to hear from you again! I've been out of the office for about 8 weeks,
but I now have time to work about 50% of the time on GConf.

Briefly, my main goals before GConf stabilises are:

- putback a working implementation of a GConf backend based around the
  BerkeleyDB toolkit

- propose some enhancements to the schema mechanism:

  * allow schema to be grouped, given a name and then re-used for unrelated keys
  
  * allow a group of keys to be named similar to a C struct and then re-used
    e.g want to define a binding for programs to handle different mime-types;
    each binding is a directory with the same set of keys. The directory
    is described using a relative rather than an absolute key. The composite
    is referred to as a sub-schema, but there is likely to be a better name:

    <sub-schema>
    <name>mime-binding</name>
    <description>Describes meta-data common to a mime-type</description>
    <schema>
    <key>name</key>
    <description>Name of this document-type</description>
    <type>string</type>
    </schema>
    
    <schema>
    <key>mime-type</key>
    <description>MIME-type name</description>
    <type>string</type>
    <default>application/binary</default>
    </schema>
    
    <schema>
    <key>icon</key>
    <description>Icon used to represent this content type</description>
    <type>string</type>
    <default>binary.gif</default>
    </schema>

    </sub-schema>
     
     This sub-schema defines a group of keys called mime-binding with three
     keys as standard: name, mime-type, and icon. A schema then needs to
     be able to refer to a sub-schema rather than having the information
     in-place for each schema. An enhancement to the <applyto> item is
     also needed: it should be necessary to indicate that a sub-schema
     can repeat itself below a certain level of the key hierarchy:
     
     <schema>
     <use-schema>mime-binding</use-schema>
     <applyto>/gnome/mime/*</applyto>
     </schema>
     
     This definition says that the sub-schema 'mime-binding' will apply to
     all directories one level below /gnome/mime. This permits the mime-binding
     to be a repeating pattern for all keys /gnome/mime/*/name,
     /gnome/mime/*/mime-type, and /gnome/mime/*/icon.

     Note that this is a suggestion only. It may be less than trivial to
     implement.
     
- test (and hopefully improve) performance of GConf when run against
  more than one database
  
- alter the documentation to reflect the fact that backends must provide
  some mechanism for concurrency control (e.g. locking). When users share
  a GConf database (e.g. they belong to a group that are administered
  collectively, or they share a common host machine), there must be
  some mechanism to ensure that users can't overwrite each others
  settings.
  
- document clearly the mechanism that GConf uses to select a database to
  write values to (currently I assume it is the first writable database in
  the user's list of configured databases, which may not be that same database
  that the value was read from.)

What is your view on the relevance and timeliness of these activities? The
BerkeleyDB work will take most of my time, but I believe that implementing
the code to reflect any design changes that make GConf a better fit for
enterprises is more urgent.

All the best,

Colm.

---