todo file
- From: Havoc Pennington <hp redhat com>
- To: gconf-list gnome org
- Subject: todo file
- Date: 26 Aug 2000 20:05:48 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]