\label{doc_contrib_api_usecases_kdb_md_md_doc_contrib_api_usecases_kdb}%
\Hypertarget{doc_contrib_api_usecases_kdb_md_md_doc_contrib_api_usecases_kdb}%
 \hypertarget{doc_contrib_api_usecases_kdb_md_autotoc_md1699}{}\doxysection{Get configuration}\label{doc_contrib_api_usecases_kdb_md_autotoc_md1699}
In {\ttfamily libelektra-\/kdb} this use case is directly implemented as the {\ttfamily \mbox{\hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()}}} function. The API has the additional precondition, that {\ttfamily \mbox{\hyperlink{group__kdb_ga844e1299a84c3fbf1d3a905c5c893ba5}{kdb\+Open()}}} was used to create a {\ttfamily KDB} instance and that a {\ttfamily Key\+Set} exists into which the configuration will be loaded.

The use case is also implemented by {\ttfamily libelektra-\/highlevel}. However, it is not a direct mapping. Instead, the {\ttfamily \mbox{\hyperlink{group__highlevel_ga45de58b05c7a8ab02f6c54ddd31a56e1}{elektra\+Open()}}} function takes care of loading configuration, which can then be accessed key by key via the {\ttfamily elektra\+Get$\ast$()} function family.\hypertarget{doc_contrib_api_usecases_kdb_md_autotoc_md1700}{}\doxysection{Set configuration}\label{doc_contrib_api_usecases_kdb_md_autotoc_md1700}
In {\ttfamily libelektra-\/kdb} this use case is directly implemented as the {\ttfamily \mbox{\hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()}}} function. The API has the additional precondition, that the current configuration has been loaded (at least once) via {\ttfamily \mbox{\hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()}}} using the same {\ttfamily KDB} instance. Even though {\ttfamily \mbox{\hyperlink{group__kdb_ga28e385fd9cb7ccfe0b2f1ed2f62453a1}{kdb\+Get()}}} must be called, the entire configuration can be overwritten via {\ttfamily \mbox{\hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()}}} as described in the use case.\hypertarget{doc_contrib_api_usecases_kdb_md_autotoc_md1701}{}\doxysection{Modify configuration}\label{doc_contrib_api_usecases_kdb_md_autotoc_md1701}
In {\ttfamily libelektra-\/kdb} this use case is directly implemented as the {\ttfamily \mbox{\hyperlink{group__kdb_ga11436b058408f83d303ca5e996832bcf}{kdb\+Set()}}} function.

The use case is also implemented by {\ttfamily libelektra-\/highlevel}. After loading the configuration via {\ttfamily \mbox{\hyperlink{group__highlevel_ga45de58b05c7a8ab02f6c54ddd31a56e1}{elektra\+Open()}}}, the {\ttfamily elektra\+Set$\ast$()} function family can be used to change individual configuration values (key by key).\hypertarget{doc_contrib_api_usecases_kdb_md_autotoc_md1702}{}\doxysection{Keeping configuration up-\/to-\/date}\label{doc_contrib_api_usecases_kdb_md_autotoc_md1702}
This use case is implemented by a combination of {\ttfamily libelektra-\/kdb}, {\ttfamily libelektra-\/notification} and at least one notification hook plugin. The notification hook plugin(s) must be enabled via the contract in {\ttfamily \mbox{\hyperlink{group__kdb_ga844e1299a84c3fbf1d3a905c5c893ba5}{kdb\+Open()}}}. Then {\ttfamily libelektra-\/kdb} will send update notifications via the notification hook plugin(s).

With the API of {\ttfamily libelektra-\/notification} applications can register callbacks to be called, when a notification is received.\hypertarget{doc_contrib_api_usecases_kdb_md_autotoc_md1703}{}\doxysection{Validating configuration with specification}\label{doc_contrib_api_usecases_kdb_md_autotoc_md1703}
This use case is implemented by a combination of {\ttfamily libelektra-\/kdb} and the spec hook plugin (normally the {\ttfamily spec} plugin). The {\ttfamily spec} plugin is enabled as a spec hook plugin by default, so this use case works out of the box.

The main validation logic is implemented in the {\ttfamily spec} plugin. 