Elektra and Other Registry-like Softwares

In the last years, many hierarchical configuration systems appeared, and all of them have the same goal: avoid configuration code rewriting, integration between applications, and separation of configuration parameters from their mother software, so then other software can use same configurations.

Here we will compare some of them with Elektra.

Windows Registry

The biggest problem with the Windows Registry is that it is Windows-specific and proprietary in design, API, and key naming conventions.

Cross platform applications can't afford to use the winregistry API because there is nothing similar in other systems.

Hopefully, Elektra will change that:

  1. Elektra is highly portable, and there are developers porting and testing Elektra on Windows.
  2. There is a winreg Elektra backend (that works as a wrapper for the Windows Registry), so a cross platform program can use Elektra API, which maps Windows Registry's keys to a more cross platform namespace.

GConf

The "G" comes from Gnome, which makes GConf part of the Gnome project. Some GConf characteristics:

  1. Architected, designed and written for desktop applications only. Its developers have whishlists to make it system global, but a lot in the essential design will have to change, making it practically a new system, and the redesign did not started yet.
  2. GConf's namespaces were not architected for global use.
  3. GConf is a daemon, so if one day it will be system global, it will represent a single point of failure.
  4. GConf storage backend are XML files, which are big, take long time and system resources to parse or update.
  5. GConf seems to be not preocupied with access permissions, making it again a good solution only for single user desktop applications.
  6. GConf is a high level software with many library dependencies, perfect for high level desktop frameworks, but its dependencies are unacceptable for low level early boot stage programs like /sbin/init. GConf's dependencies look like this:

    $ ldd /usr/lib/libgconf-2.so
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x0024b000)
        libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x03dc7000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00b66000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00dda000)
        libdl.so.2 => /lib/libdl.so.2 (0x00b8b000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x0099d000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00101000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00c7c000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00a3a000)
        libpopt.so.0 => /usr/lib/libpopt.so.0 (0x0077b000)
        /lib/ld-linux.so.2 (0x00a21000)

    This is useless for an early boot stage program (/usr/lib may be still unmounted), and for a very small OS installation that won't require desktop features, like a router, small firewall, or any other appliance. On the other hand, a program that wants to use Elektra will only link to libelektra.so which has a minimum of natural dependencies:

    $ ldd /lib/libelektra.so
        libc.so.6 => /lib/tls/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
  7. All Gnome programs use GConf, which makes them already integrated in the configuration level.
  8. In the Gnome context, Elektra fits well as a GConf backend, this way no program needs to be modified. With an additional Elektra backend for KDE's KConfig-XT, this integration will span a single framework, and we'll see KDE programs using Gnome's configurations and vice-versa.

Compared to GConf, Elektra is not a daemon, was designed from the begining for global system usage, is lightweight, is concerned about security and avoids any dependencies.

D-Conf

D-Conf generated a long discussion on FreeDesktop.org's XDG mailling list. Its objective is to standarize configuration across desktop frameworks like Gnome and KDE, so no focus is being devoted to global non-desktop system configurations.

It was very difficult to find the D-Conf website (not found in the end), and seems that all is available is that XDG discussion, and a wiki page containing analisys of what is required, and development directions.

Conclusion: D-Conf is vaporware.

LDAP and Other

UniConf

UniConf started as configuration library and daemon to be used in some specific programs. It claims to be very flexible, capable of having backends and frontends, as any configuration library can have.

Its drawbacks are, as in GConf, some dependencies, and a plus (or minus): it was developed in C++ which makes it also dependent on higher level libraries, and require client programs and programmers to be written in C++, unless they get a pure C frontend.

Some UniConf developers started to write a UniConf backend for Elektra, which means that you'll be able to use Elektra's simple API and tools, and UniConf will be responsible for all low level I/O.

Elektra and UniConf can live together in an entirely Elektrified world, leveraging UniConf flexibility as a storage backend.

Config 4 GNU

Looks like this is a dead project, since nobody talks about it for long time. Last website update was in 2004.

Very ambitious, this project claimed they will write many backends, one for each configuration file available, and after that, some can access say Samba's configurations normalized through their API and tools, what they didn't realized is that to write many different config file parsers (compilers) and keep tracking their changes, is way more difficult than to write patches for each software.

Hiveconf

This is a dead project. It is a Python library that accesses ini-style configuration files.