1 | GNOME 1.4 release (must freeze VERY soon) |
---|
2 | === |
---|
3 | |
---|
4 | The release with 1.4 is not going to be super-useful for large-scale |
---|
5 | installation administration; it's mostly just going to be a |
---|
6 | process-transparent way to store settings, limited to single |
---|
7 | workstation config files. |
---|
8 | |
---|
9 | No more source-incompatible API changes are planned for 1.4 at this |
---|
10 | time. |
---|
11 | |
---|
12 | API additions |
---|
13 | == |
---|
14 | |
---|
15 | * Implement batch gets |
---|
16 | |
---|
17 | Other |
---|
18 | == |
---|
19 | |
---|
20 | * Maintain documentation |
---|
21 | |
---|
22 | * Envisioneering |
---|
23 | |
---|
24 | Maybe 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 | |
---|
51 | Future |
---|
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 | |
---|