GConf Future Improvements

Overview of GConf.

The notes on this page converted into a "spec" of sorts

Some goals:

• make the system easier to understand for admins and programmers
• make the system cross-desktop (as in "at least in theory shareable")
• make the system possible to implement systemwide
• serve as a backend for users of the current GConf API (must be roughly compatible/semantically-equivalent, so gconfd can have a backend that chains to the new system)
• solve some of the corner cases and issues with GConf

List of important changes to make vs. current GConf, as of March 2005:

1. Implement the API primarily as a D-BUS interface. The client library should be a thin convenience layer over the D-BUS interface.

2. Move schemas out of the data store (no "install to config source" step), and instead specify their file format and how to locate the schema for a particular key on the local filesystem.

   For example, to get the schema for /apps/gedit/foobar, you might look in /usr/share/config-schemas/apps/gedit/foobar.schemas (or something like that). For efficiency:

   • we probably want to allow multiple schemas in one file
   • we probably want to do an mmap cache as has been discussed for icon themes, etc.

   One approach would be a DTD-like system where schema files are identified by a URI the app provides.

3. Have apps load the schemas directly and use the defaults found there as emergency fallbacks; have apps abort if their schemas are not found on startup. In other words schemas are a mandatory part of the app, like .glade or .ui files. This is the main function of the client library, aside from convenience wrapping of the D-BUS interface.

   This means:

   • the use of gconf is simpler
   • client apps are more robust due to emergency fallbacks
   • the client library can typecheck values for the programmer

   It's also conceptually right, since schemas should match the client; the client is the app that interprets the config values.

   This could be a nice place to try to address config key versioning; if the schema had a version, we could negotiate the version used to set the key vs. the version of the app currently accessing the key. i.e. we could do something smart with per-schema versioning, without any app programmer intervention.

List of "would be nice" changes to make vs. current GConf, as of March 2005:

1. Introduce transactions; for notifications, include a transaction ID and a "notifications remaining count" in each event.
2. Clean up the default backend to be less strange, fix the XML format, fix the file layout.
3. Have a more general and capable test suite, like the D-BUS one rather than the mess in the current gconf suite.
4. Do not support the --direct mode of operation because it bloats the client library badly. To set up default/mandatory settings, use a backend-specific application, or have a way to get the D-BUS service to do the work (require starting the daemon in other words, perhaps in point-to-point rather than in bus mode). Or perhaps have a library shared by the daemon and the config tools, and backends are done inside that library.
5. Allow any D-BUS type to be used as a value, though the client library may not support all the complicated ones.
6. Write the config daemon in paranoid D-BUS handle-OOM etc. style, since it's sometimes systemwide; also, access controls on keys will be required.
7. Have a real extensible config file in place of the "path" file
8. Simplify API, e.g. as outlined in this mail as a starting point.
9. Support "relative filename storage" in the client API (a way to store HOME/foo rather than /blah/blah/username/foo)
10. Add a way to lock down a whole directory ("/apps/panel/foo/*") in addition to single keys. This is basically a flag on the directory, in terms of implementation.
11. Consider tagging "transient session state" (e.g. window position) data in some way. The trick is how exactly to define this state, but the basic idea is data that's written often and it probably doesn't matter too much if it gets lost. Could just have a separate "GConfClient" instance for this data.

12. Consider adding real namespacing to the gconf hierarchy. For example "/org/gnome/apps/gnome-panel" or something. (Please don't do this with current gconf; if we make this the normal thing we'd probably move current gconf stuff to a namespace in automated fashion, so if you already have a namespace it will get all hosed. Also, you will be inconsistent and weird in current gconf if you do this.)

    One approach is that the schema creates a namespace. You specify a schema by URI or something, and then the keys are just "foo/bar" (no need for /apps/panel even). This also allows for schema versioning where a new schema automatically means a new copy of all the keys it defines.

13. With schemas on the client side, it's feasible to make the schema check things like ranges of integers, a list of allowed string values for enums, etc. and otherwise be more complex than a schema on the server could be. This almost certainly is not worth it unless it leads to smart handling of schema versioning, though.

Past Notes On Improvements (for historical interest)

Everything past here on the page has been merged into the above list, or is now considered wrong, or something, but I'm keeping it around for tracking.

A summer 2002 OLS paper on GConf future is here, it's a good starting point.

Some additional thoughts over time:

• We could do some quick hack to make gconfd per-session instead of per-user or per-machine, such that gconfd would exit immediately on logout and not have a lock file at all anywhere. Possible hacks are X selection (maybe via a fork/exec'd proxy to avoid gconfd connecting directly) and just hardcoding in gnome-session.
• LDAP backend, two have been written in the past to look at.
• Ettore, Jeff, and others convinced me that we need to be able to store non-preferences data such as the address book. To that end, we need to have stronger guarantees of robustness, better efficiency for large data collections, etc. Unless we use Storage or something instead?
• For desktop-independence, D-BUS may be useful if KDE supports it. D-BUS also addresses some of the needs of a client-server architecture outlined in the OLS paper.
• We should support having the apps load .schemas files directly for emergency fallback values when nothing is set in the gconf server.
• I posted some random API thoughts.
• Addition to the API thoughts: we could actually do a signal with detail, g_signal_connect (prefs, "changed::/apps/metacity/foo") with caveat that GObject may forbid slash characters in signal details, and that I believe emitting such a signal is O(n) in number of handlers regardless of handler detail.
• I'd go ahead and use GLib etc. in the API, and standardize with other desktops on the D-BUS protocol level, if we can get D-BUS (or equivalent) adopted.
• Get rid of syslog stuff, or at least only syslog for genuine serious errors.
• See two blog entries.
• See this mail and surrounding threads.
• A way to handle per-session state (that's required to be writable) might be to have a separate gconf_client_get_session() in addition to gconf_client_get_default(). i.e. just have two separate GConfClient objects, one for normal prefs that may well be all read-only, one for storing little state bits that will always be writable.