Shared configuration system
All desktops currently have their own configuration systems. They should be unified so that:
- Settings can easily be shared.
The XSettings system can be replaced (it is too limited, because only one application can change the settings).
- Notification of changes is sent to all interested applications.
- Importing/Exporting Configuration
- Looking up Configuration of System or other Applications
- Users know where their settings are saved, without having to care about which desktop an application is affiliated to.
Requirements
- Must be desktop-neutral, so that all desktops can share the same system.
- Notification of changes must be sent to all interested parties.
- Applications must be able to load a large number of settings efficiently at startup.
- Settings must cascade (the admin sets system defaults, and users may override it where they desire).
- Must be resistant to corruption (especially with concurrent changes and manual user editing).
- Should allow settings to be shared over the network (if different applications on your desktop are running on different machines).
- Keep different users' settings separate.
- Standard API / sample library implementation to access the database.
Useful bonus features:
- Light-weight enough that boot processes and small utilities can use it (possibly read-only?).
- Human readable storage format (edit config with vi, keep under version control, use diff, etc).
Issues
- A schema system to describe what values keys can have, plus translatable comments, is useful for tools like gconf-editor. There is some debate as to whether schema files are required to use the system, or an optional layer built on top of the system with the low-level backends simply storing strings (KDE and ROX store strings, with application libraries interpreting them according to a schema, while GNOME applications install schema files which are understood by the underlying configuration daemon).
- Are only preferences to be stored? A network-transparent per-user storage system with change notification could be useful for many things, such as storing bookmarks, your address book, a list of recently edited files, etc. We must make sure that the project does not try to do everything.
- Do we have a single way of actually storing the settings, or just an API with pluggable backends? Pluggable backends allow the same API to be used in different environments; a system daemon might want to store values to a local text file without change notification, while a desktop application in a large company might access settings via a remote SQL database. A single backend can't cover all cases, and would prevent some people from adopting the system. The effect of this would be that programmers would choose a configuration system per-application, rather than sysadmins choosing a system per-computer.
Plan
This specification is expected to use the Base directory spec for the location of configuration files (under *~/.config* by default).
Ideally, the system should be fast but also network transparent. Possibly, applications could read the database directly if running on the same machine as the config files, or read them via the notification process if not.
We should define a simple API for setting and getting configuration settings and provide a small library that implements it. It should be possible to use multiple backends (XML files, database, etc) to actually store the settings.
Change notification could be done using D-BUS.
References
Havoc's description of gconf and his future plans (PDF) (starting at page 414). See also, updated future plans.
UniConf: UniConf lets you build up a configuration tree by 'mounting' generators (like filesystems) onto it. Generators can store keys in memory, on disk, through a database, through gconf, etc, and can be used to combine other trees (fallbacks, cascading, caching, union, etc). Currently, applications each build their own namespace at start-up, or you can use the "auto" moniker to allow for a user to make all apps use a database for config, or all use gconf, etc, rather than hard-coding it in the apps. It can operate with or without a demon. It supports both transactions and notifications.
Common configuration namespace thread (includes description of KDE's namespace).
Configuration API thread (requirements, types, backends, schemas)
Config4GNU: An abstraction layer over many different config file syntaxes (.ini files, fstab, apache, etc). For example to an editor all config files are presented as a XML structure with comments available options and defaults. This is mainly intended for system-level configuration, rather than for user settings. It doesn't not handle notification of changes. Several interfaces to access the complete configuration tree exist, yet the applications themselves are not required to switch to them. A special feature is that the semantic meta-data (options, types, assumed defaults and even wizard logic etc.) for applications are kept as separate description textfiles and thus can be updated together with the app (idealy even kept in sync in cvs) without the need to update or recompile Config4GNU or any frontends.
Elektra Project: "Elektra provides a sigle unified system-wide namespace to represent keys, and a clean API to access it, with many language bindings and some backends." Elektra uses backends to store every (key, value) pair. That can be a separate file in the filesystem, ini-style like, berkleydb or everything else. If locking, networking or cascading is supported is decided by the backend. There is no backend available now for networking. There are no dependencies (except of libc) of the core library. The backends may add dependency (like berkleydb, gconf).
D-Conf: Wiki page with more plans for freedesktop.org config system.