www/ Specifications/ config-spec

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.
  • Light-weight enough that boot processes and small utilities can use it.
  • Human readable storage format (edit config with vi, keep under version control, use diff, etc).
  • Change notification should be done using D-BUS.

Status 05.08.2020

As discussed in the XDG list, Elektra is preparing a specification which fulfills all the requirements above.

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: "Elektra provides a single unified system-wide namespace to represent keys, and a clean API to access it, with many language bindings and backends." Elektra uses backends to store every (key, value) pair. That can be XML, INI-style, JSON or everything else. If locking, networking or notification is supported is decided during mounting of backends. 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.