/**

@page ds_page Datastores

Sysrepo supports \b startup, \b running and \b candidate configuration datastores. Each configuration
session can perform operations on any of them. On session start the initial datastore
is selected. All subsequent calls are tied to the chosen datastore. The datastore which
the session is operating can be changed during the lifetime of the session using ::sr_session_switch_ds.

The changes made within a session are not applied into the datastore
until ::sr_commit is requested. While not committed, changes are visible only
within the same configuration session. This applies for all three datastores,
but \b candidate has some differences, which are mentioned in its section.


@section sds Startup Datastore
Startup datastore contains the configuration data that should be loaded by the
controlled application or service when it starts. Each sysrepo-enabled application
or service supports at least this datastore.


@section rds Running Datastore
Running datastore contains currently applied configuration and state data
of a controlled application or service. If the application is not running at the
moment for whatever reason, it will have no data in the running datastore
(and the attempt to alter its configuration in running datastore will result in an error).

Not all applications support this datastore. If an application does not support running
datastore, it won't have any data in it, regardless of whether it is running or not.

To support running datastore, the application needs to subscribe for notifications about the
changes made in the datastore. After the subscription, the data on subscribed paths
will be copied from startup to running datastore and become available for retrieval
and modification via running datastore. When a new configuration is committed into the running datastore, subscribed
application is informed about it and should start using it.

@note Be aware that changes in running datastore are not persistent and will
be lost after the application or the system restarts - an explicit copy-config
from running to startup datastore is needed to make the changes persistent
after restarts (see ::sr_copy_config).

@section cds Candidate Datastore
The candidate configuration is a full configuration data set that serves as a work
place for creating and manipulating configuration data. Every session always has
a separate candidate datastore with changes never being visible in other sessions.
::sr_commit operation only validates the changes and optionally performs a NACM check,
if NACM is enabled. To apply these changes to a datastore visible for all the sessions
and applications, use copy-config (see ::sr_copy_config).

*/
