elektra-spec(7) -- spec namespace

spec is a special namespace that describes via meta data the semantics of individual keys.

Most importantly it:

0. describes which keys are of interest to the application

1. describes the meta data to be copied to every key
2. describes how the cascading lookup works
3. describes the mountpoints including the plugins needed for them

It is, however, not limited to this but can express any other key database semantics (new plugins might be necessary, though).

Application

The most simple use is to enlist all keys that will be used by an application and maybe give a description for them (we use ini syntax in this document):

``` [mykey]

[folder/anotherkey] description = set this key if you want another behaviour ```

So Keys in spec allow us to specify which keys are read by the application. The description key will be copied (referred to) to folder/anotherkey of any namespace, so that it can easily be accessed.

Cascading Lookup

Other features are directly implemented in ksLookup. When cascading keys (those starting with /) are used following features are now available (in the meta data of respective spec-keys):

• override/#: use these keys in favour of the key itself (note that # is the syntax for arrays, e.g. #0 for the first element, #_10 for the 11th and so on)
• namespace/#: instead of using all namespaces in the predefined order, one can specify which namespaces should be searched in which order
• fallback/#: when no key was found in any of the (specified) namespaces the fallback-keys will be searched
• default: this value will be used if nothing else was found

E.g.

``` [promise] default=20 fallback/#0=/somewhere/else namespace/#0=user ```

1. When this file is mounted to spec/sw/app/#0 we specify, that for the key /sw/app/#0/promise only the namespace user should be used.
2. If this key was not found, but /somewhere/else is present, we will use this key instead. The fallback technique is very powerful: it allows us to have (recursive) links between applications. In the example above, the application is tricked in receiving e.g. the key user/somewhere/else when promise was not available.
3. The value 20 will be used as default, even if no configuration file is found.

Note that the fallback, override and cascading works on key level, and not like most other systems have implemented, on configuration file level.

Validation

You can tag any key using the check meta data so that it will be validated.

For example:

``` [folder/anotherkey] check/validation = abc.* check/validation/message = def does not start with abc ```

Mounting

In the spec namespace you can also specify mountpoints. First you need the meta key mountpoint and a configuration file name. Otherwise, it basically works in the same way as the contracts in plugins using infos and config:

``` [] mountpoint=file.abc config/plugin/code/escape = 40 config/plugin/lua#abc/script = abc_storage.lua infos/author = Markus Raab infos/needs = resolver_abc rename code lua::abc infos/recommends = hexcode ```

SEE ALSO

• see application integration tutorial (towards end)
• see namespaces tutorial
• elektra-namespaces(7)
• elektra-cascading(7)
• elektra-plugins-ordering(7)