From Elektra Initiative
There are only two types of values (and their variations) that can be stored: text (or string) and binary
- Text or String
- Handled as pure text. Regardeless of the charset being used, these values are always stored as UTF-8. This ensures very strong internationalization and migration capabilities, while keeping simplicity.
- Binary
- A stream of bytes, not necessarily text. It is recommended that you avoid using binary values because UNIX system administrators tend to consider them as unmanageable blackboxes. Anyway, the value will be encoded into pure text format based on hexadecimal digits, for openness and ease of administration. This data type should also be avoided because it is less efficient.
- Extended Text or Extended String
- Handled exactly as the String type. The internal number for the String type above is 40, and Extended Strings can have internal numbers between 41 and 255. This way, users may define their own types but still having Elektra handle it correctly for them.
- Extended Binary
- Handled exactly as the Binary type. The internal number for the Binary type above is 20, and Extended Binaries can have internal numbers between 21 and 39. This way, users may define their own types but still having Elektra handle it correctly for them.
- Folder
- It can't store a value, but, as a directory in a filesystem, it serves as a way to group correlated keys.
- Link
- It is a link to another key. They work as symbolic links in the filesystem: when trying to access them, you will actually access the key they point to. The API also provides ways to access these special keys without dereferencing them.
There are very good reasons why types like Integer, Time, Font, List, etc were not implemented: Elektra was designed to be usefull for any type of program, so having more specific data types implicates in the definition of value limits, separators in the storage format, etc, that may be good for some application and bad for other.
An application that needs special value types can use the Extended types described above, and handle the semantics for itself. Frameworks like KDE or Gnome may define global types as Font, Colour, etc.
Key Meta Data
Besides the key name and the value, each key has other attributes:
Owner's User and Group
This is a system's UID and GID equal to the ones found in regular files' attributes.
Access Permissions
Filesystem-like access permissions for user, group and others.
Modification, Access and Stat Times
Last time a key was modified, readed and stated (listed), respectively.
Key Comment
Pretty much as a configuration file comment. Not intended to be used in GUI applications, because it isn't internationalizable.