Early work on GConf-based Beagle config system

I’ve been continuing work on making a configuration system for Beagle. We’ve decided to go for a GConf-based system if things can work out. This is a learning experience for me as I’ve never dealt with GConf before.

A few notes on the design, which was mostly spurred from the XML-based system I drafted previously.

  • A new class, Beagle.Util.Conf, handles the configuration. Currently only reading, but eventually will also handle writing and live notification of updates.
  • We have a schema file, which contains the schemas for the keys we use. Our keys are kept under /apps/beagle
  • We use gconfsharp-schemagen to generate a couple of new classes, Beagle.Util.Settings and Beagle.Util.SettingKeys.
  • We use gconftool-2 to install the schema and default keys

Before I go much further, there’s a few issues that need to be addressed.

  1. gconftool-2 –makefile-install-rule seems to overwrite any previous settings. This would mean users losing their settings on every upgrade/recompile?
  2. I can’t find much documentation, but the purpose of gconfsharp-schemagen seems to aim at creating convenient access classes to the GConf settings. This is pretty much the same as the aim behind Beagle.Util.Conf – do we really need to duplicate?

To elaborate on point 2, the classes autogenerated by gconfsharp-schemagen are quite basic. Ideally we need to be aware of things like threading, e.g. using the code already written for Beagle.Daemon.GConfThreadHelper. It would also need to be extended for things such as the command line configuration tool, beagle-config.

Where to go from here? We could either ditch the gconfsharp-schemagen thing and rely on always hardcoding the schema paths and accessors into the hand-crafted Beagle.Util.Conf class, or we could write our own autogeneration tool to produce something like Beagle.Util.Conf from the schema file, with the detail and functionality that we need…

This almost of boils down to one important implementation detail: If we were to hand-craft Beagle.Util.Conf (maybe using gconfsharp-schemagen as a base) then it would be quite possible in the future to change our storage method to something else, simply by modifying the Beagle.Util.Conf methods. On the other hand, if we go for a purely automated way using automatic class generation from the schemas and other metadata, then it most likely means hardcoding GConf specifics into the areas of beagle which are to use these configuration values, making future changes to another system more difficult…

5 thoughts on “Early work on GConf-based Beagle config system”

  1. Brent

    Aren’t user’s keys stored in ~/.gconf/, so unless you change the schema completely (key names, etc)
    how would users lose their settings?

  2. dsd Post author

    Brent: My quick tests indicate that “gconftool-2 –makefile-install-rule beagle.schemas” actually overwrites the current settings with the defaults from the schema. I’ve given this some thought, and I don’t think we’ll even use schemas (see my next blog post, coming very soon). Thinking about this even more, this (using the Makefile to install the schema) would be very broken anyway, as who says that the user compiling beagle is the same as the user(s) who will use beagle.

  3. Pingback: dsd’s weblog » Blog Archive » Why even use a schema at all?

  4. Pingback: dsd’s weblog » Blog Archive » Planet Beagle

Comments are closed.