Re: todo file

[Colm Smyth <Colm Smyth ireland sun com>]

Hi,

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

Colm.

>Delivered-To: gconf-list@gnome.org
>X-Authentication-Warning: icon.labs.redhat.com: hp set sender to hp@redhat.com 
using -f
>To: gconf-list@gnome.org
>Subject: todo file
>From: Havoc Pennington <hp@redhat.com>
>User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
>MIME-Version: 1.0
>X-BeenThere: gconf-list@gnome.org
>X-Loop: gconf-list@gnome.org
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion of the GConf library <gconf-list.gnome.org>
>
>
>Hi,
>
>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.
>
>Havoc
>
>* 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
>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