Contents |
Elektra now supports multiple backends at once. That means every path like user/sw or system/filesystems can reside in a different backend.
Use cases for backend mounting: 1. There are many configuration files lying on every system that can't be replaced for various reasons. These files can be faded in into the global elektra namespace without any notice by applications using these files. Backends for /etc/fstab, /etc/mtab and /etc/passwd exist right now.
2. Users or administrators might be accustomed to certain files or syntax without wanting to change the whole configuration using elektra. The mounting technique allows them to choose.
3. Specific programs may have very complex and large configuration. Binary files with index may give them a fairly better performance without missing the connection to the global namespace.
4. Configuration provided by network or local daemons for notification and caching can't be used for every program. Configuration related to bootup or some system users needs to be available without them, but should also be accessed by applications needing configuration from network.
If you are not convinced - Its just about choice and you can go on using only one backend.
And if you think "why not use the perfect backend", we discussed about it a lot and why have only one if you can have all ;)
See http://www.libelektra.org/Backends what is and might be possible.
These 4 core functions do now everything related to backend communication. All the other functions are build upon it. This makes backend writing much easier. Removing and Stat works by setting a flag in a key.
KDBHandle * is now a typedef for the _KDBHandle structure and not a void* pointer.
Starting with ksNew you can give a hint how large the keyset may grow. You can also give a list of keys which should be added at startup.
ksGenerate() makes use of that and generates a keyset in C-Code which you can use in your applications or for regression testing.
The internal structure of keyset is now a growing (and shrinking) array. Keys may belong to multiple keysets. The last ksDel() deletes the key automatically (reference counter).
This implementation is a lot faster, the benchmark for 0.7.0rc1 is better than for 0.6.*, even though the mounting logic takes a bit of performance, but very little and something about zero when no backend is mounted.
The sorting does automatically takes place, whenever needed.
ksLookupByName is implemented by binary search, it now goes with log(n) instead of slow n. That means in 1000 keys the key will be found in about 10 steps, in 10.000 keys only in 20 steps.
The key now uses sizes for name, owner, value and comment. This allows a complete new technique of serializing: keyCompose(). With that you can serialize a key without a single malloc(). keySerialize() is rewritten for the new key struct too.
The directory is now marked by the executable flags. That means you can disallow other users or groups to list your keys.
Some backends fullfill the whole specification of kdbGet_template() and kdbSet_template() and can be used by any program for any purpose. Other backends have principle limitations and do not fullfill the specification, but can do more than enough to be useful.
To handle this problem we created a data structure describing what capabilites a backend does not have. With that technique you can use the testing framework from early steps developing the backend on. To do so, just declare your backend can do nothing and delete step by step while your backend evolves.
There are some issues with the capabilities status quo and the backend interface will change during 0.7.x.
There is now a large testing framework with 11 collections with up to 8128 tests each. Most conditions of the whole sourcecode are checked, that means if you random change something in the code you have a good chance that a test case will fail.
There are 2 new flags:
--enable-valgrind-tests Allows you to enable valgrind for testing, a full list of memory leaks is printed after every test. --enable-gcov Use it to see what lines of code are covered by tests.
The testcases are without any memory leak (dozens of leaks are fixed, especially in xml code).
There are bindings for cpp, python and scheme in beta status, which hopefully will be finished towards 0.7.0.
