GConf Future Improvements

Overview of GConf.

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

Some goals:

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:

    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:

    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: