| 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 | |
|---|
| 105 | * The design of the client-server architecture is horked, overcomplicating |
|---|
| 106 | GConf.idl; the client should remember all its state (listeners, etc.), |
|---|
| 107 | and when the server disappears (we lose the connection to it), the |
|---|
| 108 | client resends its state; thus eliminating the saved state file |
|---|
| 109 | and making things more robust. |
|---|
| 110 | |
|---|
