From Elektra Initiative

Contents 1 ini 2 About 3 Generation of new files 4 Meta Content 5 Future Formats

ini

Developer: Markus

About

Official Stuff about the backend.

This is a ini-style backend. Key/Value Pairs are stored in files in following scheme:

key1=value1;comment
[subsection]
keysub=value2;comment
#include <user/folder/dir>
[sub/subsection]
keysubsub=value3;
empty=;
#link <user/app/myapp/key>

The design goal is to have a situation as today, but unified. There should be per application one configuration file in $HOME and in /etc. See TreeLayout for more Information.

From security standpoint it is between filesys (most secure possible) and single configuration file (like berkleydb).

Ini makes it possible that users can edit their own config files.

Generation of new files

suppose following key is generated:

user/dir/file/key

this will do following:

1. Create the folder /home/markus/.kdb/user/dir/
2. Create the file /home/markus/.kdb/user/dir/file
3. Add the line key=value in the file

When afterwards following key will be set:

user/dir/key

this will do the following:

1. Create the file /home/markus/.kdb/user/dir/CONTENT; This is standard if you want to have a key inside a real folder. Thus you are not allowed to call files CONTENT. This name may be changed?
2. Add the line key=value in the file

Or when afterwards the following key will be set:

user/dir/file/subdir/key

this will do the foloowing:

1. Create the section [subdir] at the end of the file if it does not exist by now.
2. Add the line key=value in the proper section

Meta Content

There are also Meta Constructs which allow do have programmable decicions, include statements and links. They are very primitive (by concept) now.

#include <user/dir/commonkeys>

Allow to include other dirs. This will be ignored by default when you just get a key. But if you use keyGetKeys in a recursive way it will also get the keys out of the section.

A string replacement will take place. If this example is in user/sw/app the key user/dir/commonkeys/key will be renamed to user/sw/app/key.

#link name <user/link/key/here>

The Key name will have the contents from user/link/key/here.

Future Formats

ini format will be only the first format out of the source code written now. Once the code is stable, well working and cleaned up it is planned to support various different formats.

1. Ansi C Port: POSIX should not be required if you don't want file locking and so on.
2. Xorg Format
3. C-Style format (xinetd)
4. bash like format