Many people compare GConf to the windows registry. The logic goes if it is a hierarchical database of key, value pairs holding system configuration data, it must be bad. That is a very superficial look at what is actually a very useful piece of technology. Is it the next thing since sliced bread (sliced bread having been invented the previous winter)? Not really, but it does enable some pretty nifty things. You see, what I am really interested in is the business logic that GConf enforces rather than the way it represents data.
David Zeuthen keyed me into this thought train, and it really solidified for me while moving Fedora to use gnome-mount instead of fstab-sync (and standard mount) for auto-mounting drives. GConf enforces policy through a couple of layers which rely on a couple of simple rules for determining which layer an application will get an answer to a query from. There is the system layer where all the default values are stored and then there is the user layer where the user can make changes based on their preferences. User always trumps system except for when a key is marked as mandatory. In this case the key is locked down and can not be overridden by the user. This is all very simple but also very powerful. This one system enforces a policy that is both flexable (the user can change the system defaults) and secure (the admin can lock down any keys they do not wish the user to mess with).
How does this relate to gnome-mount? Gnome-mount gets its policy from GConf. Now users can set a certain set of limited options on things like USB keys (such as mounting it sync). Administrators can also easily block anyone from mounting anything at all. NetworkManager works in a similar fashion as does Gnome Power Manager.
Still not convinced? Throw into the mix Sabayon and Stateless Linux, and GConf begins to look more enticing. With Sabayon and administrator can set up a desktop policy simply by configuring a desktop session. Sabyon captures GConf key changes (as well as some other backends such as firefox) and then spits out a configuration bundle IS departments can use to deploy locked down desktops with. Integrating an application with GConf means it can instantly benefit from Sabyon.
What about Stateless Linux? In a stateless world root can not be written to (think live CDs), but we do want to allow the user to save state (think a USB key or network mounted home directory). Doing things the GConf way gets you there in a hurry. We do this in NetworkManager. If a user sets a network up to connect via VPN this configuration is stored in GConf (with the sensitive parts in gnome-keyring I believe). No touching of configurations files in /etc is needed to connect to a VPN network or any network that NetworkManager can handle.
Sure you can do all this without GConf. It isn’t going to save the world and like most things it isn’t always the perfect solution. What it is is a tool which enforces a couple of simple rules for making an application integrate better with the whole system. Security, flexibility and manageability – that is my triple verb of the day.
Update: I forgot to mention that I also use this approach to a lesser extent for desktop configuration of USB printers when they can’t be auto-detected. I am looking to making it more robust.
Update 2: Hey Daniel how about Secure, Manage, Control[read this post in: ar de es fr it ja ko pt ru zh-CN ]