Re: todo file


I have one more item to also go on the todo list:

* Define XML DTD to represent updates to GConf (both set's and key-removes);
  augment gconftool to read and write this data format
The documentation updates include:

- backends need to support concurrency control as there may be multiple
  gconfd processes accessing a single shared GConf database
- some clarification about writes to the database (make clear that
  a write occurs in the first non-readonly database, not necessarily
  the same database that the key was read from


>X-Authentication-Warning: hp set sender to 
using -f
>Subject: todo file
>From: Havoc Pennington <>
>User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
>MIME-Version: 1.0
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion of the GConf library <>
>I stuck the following TODO file in CVS, as a start. If I forgot
>anything let me know.
>An issue I mentioned here is that Berkeley DB changes incompatibly in
>API and on-disk format fairly frequently. This has been a problem in
>the past with other applications - I think we're fine as long as we
>can dlopen() two versions of it, and then name the backends "db2",
>"db3", etc., but need to consider this with that backend.
>I'm thinking of working on gconfd life cycle and robustness against
>crashing next week.
>* Move to a cut-and-pasted version of GError from GLib unstable branch, 
>  replacing GConfError.
>* Berkeley DB backend (note: consider issues surrounding various incompatible 
>  versions of DB and historical problems with the upgrade path, cf. 
>  RPM and gnome-mime-db)
>* Performance tuning
>* Document locking issues for backends (backends should perform
>  their own locking, etc.)
>* Document which database GConf will write to given multiple 
>  writeable databases
>* Fix spelling of "writable" throughout, or at least
>  in public API (s/writeable/writable/g)
>* Implement a way for backends to notify gconfd of changes they detect
>* Implement a "database map"; this would be a tree structure (similar
>  in implementation to GConfListeners). Rather than storing listeners
>  at the tree nodes, store a list of databases in order, and 
>  readability/writability of each database. Create a config file
>  (perhaps in the GMarkup XML subset from glib 2.0) for configuring
>  the database map. Figure out whether this can entirely replace
>  the readable/writable methods from the backend vtable.
>  It likely replaces the gconf/path configuration file. (Essentially
>  the idea is a database path per key/directory, instead of a 
>  global database path, giving administrators more flexibility.)
>  Details to be figured out.
>* GUI admin tool, and GUI user tool (are these the same?)
>* Thread support for scalability; may require ORBit thread safety?
>  Or a protocol with oneway CORBA methods (client requests a value,
>  gconfd calls back when it has the value)
>* Robustness against gconfd exit or crash; probably by logging
>  the current list of clients to a file
>* Life cycle management for gconfd (exit if no clients are alive, 
>  maybe ping clients periodically)
>* Maintain documentation
>* API so clients can find out if they can write to a given key
>  (gconf_key_is_writable() or the like)
>* Implement the default error handlers in GConfClient
>Gconf-list mailing list

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]