sr_plugins.dox

/**
@page sr_plugins sysrepo Plugins

Sysrepo itself supports 2 kinds of plugins not to be confused with `sysrepo-plugind` plugins. **Datastore plugins**
define a set of callbacks that implement all the operations performed on a datastore allowing to implement a completely
custom datastore. Every datastore for every YANG module can use a different datastore implementation. **Notification
plugins** is the exact same concept used for implementing storage of notifications stored for replay.

There are 2 main reasons for implementing a custom datastore plugin. Firstly, it is almost a necessity when adding
Sysrepo support for an existing application/daemon with its own configuration. Normally, the configuration would have
to be stored both in the app configuration and a Sysrepo datastore, which has severe disadvantages. Not only is the
configuration stored twice but keeping both configurations consistent is next to impossible, which then causes problems
if different data are stored in each configuration. Datastore plugin essentially allows to hook the app configuration
directly into Sysrepo so all the Sysrepo datastore operations such as load or store will be performed using the app
configuration.

Secondly, the performance. The default datastore implementation is using *libyang* JSON files that are completely generic
and can store any YANG data but some operations may take much longer than necessary and even require more space than
a specialized datastore would. The main disadvantage of JSON files in terms of efficiency is performing small changes
on large data. In this case the whole data must be parsed, the change performed, and the whole updated data written
back. Instead, another datastore may be able to store the change directly without parsing and printing all the other
stored data. As for the space required, if implementing a datastore for a specific YANG module, the data structure can
fully depend on the schema nodes defined in the module and hence avoid storing any redundant information. Finally,
note that the internal JSON datastore is also implemented as a datastore plugin so it can be used as an example
implementation.

@ref dsplg_api

@ref ntfplg_api

@section sr_ds_plg_mongo MONGO DS plugin

`MONGO DS` plugin works as a database client. It connects and sends necessary commands directly to the MongoDB database
server. It connects via the **libmongoc** library API and uses its functions to further communicate with the server.
In MongoDB database there is a hierarchy of data. All data are stored in records which are then stored in collections
which are then stored in databases. Each datastore for which `MONGO DS` plugin was deployed has its own database.
The name of the database consists of a `sr_` prefix and the name of the datastore, e.g. `sr_factory-default`. Data of each
particular YANG module are then stored in a collection within the particular database. In order to avoid data
conflicts the databases with the names `sr_startup`, `sr_running`, `sr_candidate`, `sr_operational` and `sr_factory-default`
can only be used by the sysrepo library.

In order for the authentication (see README) to work the configured user has to have a read and a write permission on
following databases: `sr_startup`, `sr_running`, `sr_candidate`, `sr_operational` and `sr_factory-default`.

@section sr_ds_plg_redis REDIS DS plugin

`REDIS DS` plugin first connects to the Redis Stack database server via **hiredis** library API and then sends 
commands to the server using its functions. In Redis database all data are stored together. In order to differentiate between them,
the keys have to be prefixed. The prefix for all sysrepo data is `sr:` and in order to avoid data conflicts the keys and indexes
starting with a `sr:` prefix can only be used by the sysrepo library.

In Redis database there are certain limits with respect to data management which cannot be set to unlimited. The maximum amount
of data which can be loaded from the database at once is set to one trillion. Some of these limits are enforced via the server
configuration and since the sysrepo library does not have an access to the server's configuration file, it sets these limits
via commands (more specifically the options MAXAGGREGATERESULTS and MAXEXPANSIONS).

In order for the authentication (see README) to work the user has to have the right to operate on all keys and indexes with the prefix `sr:` and 
at least the right to use these following commands: `AUTH`, `FT.CONFIG SET`, `FT.AGGREGATE`, `FT.CURSOR READ`, `FT.CREATE`,
`FT.DROPINDEX`, `HSET`, `HGET`, `SET`, `GET`, `DEL`, `COPY`. Redis supports categories of commands, so to enable all of these commands
at once you only have to enable a category containing all of them, e.g. `@all`.

*/