Contents |
Just to provide an hierarchy to store values don't turn directory servers into configuration systems. They were actualy not designed for that. Directory servers are hierarchical databases that most leafs have the same shape (translated into schemas, in the LDAP terminology).
If you want to change that, an LDAP schema must be written. In other words, each leaf of your configuration tree must have a different schema. This will make your application development more difficult, and other softwares will have problems accessing your's keys.
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 to be written in C++. Since most base OS softwares were written in C, it is difficult and cultural chalenging to make them use a C++ library.
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.
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.
This is a dead project. It is a set of Python scripts that access ini-style configuration files.
