DConf and Elektra

[Magnus Bergman]

On Sat, 18 Jun 2005 20:13:53 +0200 (MEST)
"Fabian Zeindl" <fabian.zeindl at gmx.at> wrote:

> Hi
> 
> I read through
> http://freax.be/wiki/index.php/Temporary_location_for_D-Conf_specs
> and want to correct some information about Elektra:
> 
> "All key-value pairs are stored in clear-text files, UTF-8 encoded.
> All old charsets are also supported, with automatic transparent
> conversion to and from UTF-8."

I would say that statement is entirely wrong. There is not even any
backend that stores data in clear-text files (except indirectly via
the GConf backend). The elektra API supports just two datatypes (correct
me if I'm wrong); Binary data chunks (which according to the
documentation is intended for application specific data types) and
text, which functions alike but with the transparent charset conversion.

About the statement "(Elektra) Is NOT something that accesses SQL/
relational databases"; nothing hinders anyone from making an SQL
database backend. And if someone does I'm sure the maintainer of
Elektra would be glad to include it in the distribution.

> Elektra can change it's Backend. The intended idea is, that the API
> stays the same for the programs while the Backend can be changed from
> Files to Databases to everything else imaginable. The File-Backend is
> the one which is "delivered" when you download Elektra in it's
> current state.

There is also (at least) a berkly-db and a GConf backend shipped. The
default backend (which on installation is the file backend) is not
decided at compile time but simply with a symlink. The shortcoming I
see is that Elekra only support one backend per process.

> And I have a question too: Is DConf intended as configuration system
> for almost every application (even the systemapps in /etc) or just
> for Gnome/Kde Apps? Cause I think there are many applications
> developers which wouldn't use a unique system if it needs a daemon to
> be run. Maybe there's a possibility to create a system which could be
> run with a daemon and (with reduced functionality) without daemon too?

I agree with you here. The answer I got was that it is only
intended for desktop applications, but I fail to see way desktop
applications has to be so special. There is a thread about running both
with and without a daemon (in general but it certainly applies to
this). My idea is (in short) that the communication with the
configuration daemon (or any configuration daemon) could be handled by
just another backend, and that the handling of the backends is moved to
the library and finally that the daemon also uses the same library as
the applications. Something like this:

                 ,-----.                      ,-----.
                 | BE1 |                      | BE1 |
 ,-----. ,-----./>-----<   ,--------. ,-----./`-----'
 | App |-| Lib |-| BE2 |-P-| Daemon |-| Lib |
 `-----' `-----'\>-----<   `--------' `-----'\,-----.
                 | BE3 |                      | BE3 |
                 `-----'                      `-----'

"Lib" is the the same library used by both the application and the
daemon. "BEx" are the backends. "BE2" is the backend which contacts the
daemon using a specified protocol ("P"). Think of these two scenarios:

1) The daemon isn't available but if the application doesn't depend on
the features provided by the daemon and can access the backends in
process.

2) The application depends heavily on the features provided be the
daemon and will use it if it's available.

Note that it's theoretically possible that the a backend for some
database server (for example) can provide every feature necessary so
the daemon never becomes required.