source: trunk/third/GConf/TODO @ 15500

Revision 15500, 3.6 KB checked in by ghudson, 24 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r15499, which included commits to RCS files with non-trunk default branches.
Line 
1GNOME 1.4 release (must freeze VERY soon)
2===
3
4The release with 1.4 is not going to be super-useful for large-scale
5installation administration; it's mostly just going to be a
6process-transparent way to store settings, limited to single
7workstation config files.
8
9No more source-incompatible API changes are planned for 1.4 at this
10time.
11
12API additions
13==
14
15* Implement batch gets
16
17Other
18==
19
20* Maintain documentation
21
22* Envisioneering
23
24Maybe 1.4
25===
26
27* Implement dump/slurp functionality (define XML DTD to represent
28  modifications to the database; augment gconftool to be able to
29  write out the current state of the database in this format,
30  and also apply the changes given in the format)
31
32* Make it so that once the first notification of a change in a GConfChangeSet
33  is delivered, the other values will be retrieved by gconf_get() and
34  gconf_client_get(), which means a way to invalidate GConfClient
35  cached stuff, and doing the setting of all values in the changeset
36  before the notifications.
37
38* Allow various currently-hardcoded items to be set from environment variables
39  or a config file ("home" directory to use, timeout lengths, etc. are
40  some candidates).
41
42* "Laptop mode" where GConf avoids touching the disk much
43
44* Implement server-side search (Kind of hard to actually implement
45  on the server, at least in any sort of fast way, and
46  all other gconf-using apps will block while the server is searching,
47  without some tricks to let the main loop run sometimes, so, dunno.)
48
49* Implement a way to get the GConfMetaInfo
50
51Future
52===
53
54* Berkeley DB backend (note: consider issues surrounding various incompatible
55  versions of DB and historical problems with the upgrade path, cf.
56  RPM and gnome-mime-db)
57
58* Performance tuning
59
60* Document locking issues for backends (backends should perform
61  their own locking, handle concurrency, etc.)
62
63* Document which database GConf will write to given multiple
64  writeable databases (i.e. the first one it can write to,
65  at the moment, maybe eventually the "database map" will
66  specify which it writes to)
67
68* Implement a way for backends to notify gconfd of changes they detect
69
70* Implement a "database map"; this would be a tree structure (similar
71  in implementation to GConfListeners). Rather than storing listeners
72  at the tree nodes, store a list of databases in order, and
73  readability/writability of each database. Create a config file
74  (perhaps in the GMarkup XML subset from glib 2.0) for configuring
75  the database map. Figure out whether this can entirely replace
76  the readable/writable methods from the backend vtable.
77  It likely replaces the gconf/path configuration file. (Essentially
78  the idea is a database path per key/directory, instead of a
79  global database path, giving administrators more flexibility.)
80
81  Also, aliases for paths, and way for apps to install a suggested
82  default database alias ("per_display" "per_homedir" etc.)
83  (See gconf-list post)
84
85  Details to be figured out.
86
87* GUI admin tool, and GUI user tool (are these the same?)
88
89* Thread support for scalability; may require ORBit thread safety?
90  Or a protocol with oneway CORBA methods (client requests a value,
91  gconfd calls back when it has the value)
92
93* Fix non-default GConfEngines: this means propagating change
94  notifications from them to other engines with the same
95  databases. Or maybe instead we should use the mechanism
96  used when the same database is in two gconfds (backend
97  notifies us of changes).
98
99  Suspect that all notification has to come from the backend,
100  this is the only way to get sane behavior if _some_ notification
101  comes from the backend. Hmm.
102
103* Use a real DTD and a nicer structure for the XML backend format
104
Note: See TracBrowser for help on using the repository browser.