diff --git a/docs/manual/abstractions/index.html b/docs/manual/abstractions/index.html index 4260a34a..12ade639 100644 --- a/docs/manual/abstractions/index.html +++ b/docs/manual/abstractions/index.html @@ -19,8 +19,8 @@ This time is a 64-bit time with a similar structure than a NTP timestamp (but with a different epoch):
This time gives a theoretical resolution of (0xF * 10^9 / 2^32) = 3.5 nanoseconds.
It’s counter part guarantees that the same time cannot be generated twice and that the happened-before relationship is preserved.
The UUID of the Zenoh router that generated the time.
Such a timestamp allows Zenoh to guarantee that each value introduced into the system has a unique timestamp, and that those timestamps (and therefore the values) can be ordered in the same way at any point of the system, without the need of any consensus algorithm.
An entity registering interest for any change (put or delete) to a value associated with a key matching the specified key expression.
An entity declaring that it will be updating the key/value with keys matching a given key expression.
A computation registered at a specific key expression.
This computation can be triggered by a get
operation on a selector matching this key expression.
-The computation function will receive the selector as parameters.
Storages are both a queryable and subscriber. They
zenohd
, the reference implementation of a Zenoh node, supports storages through the storages
plugin.
Since there exist many ways to implement the storing part of the process, the storages
plugin relies on dynamically loaded volumes to do the actual value-storing. Each volume has its own tradeoffs, as well as potential uses besides acting as a database for zenohd
.
The key space of Zenoh dedicate to administer a Zenoh router and its plugins.
-It is accessible via regular get/put on Zenoh, under the @/router/<router-id>
prefix, where
+The computation function will receive the selector as parameters.
Storages are both a queryable and subscriber. They
zenohd
, the reference implementation of a Zenoh node, supports storages through the storages
plugin.
Since there exist many ways to implement the storing part of the process, the storages
plugin relies on dynamically loaded volumes to do the actual value-storing. Each volume has its own tradeoffs, as well as potential uses besides acting as a database for zenohd
.
The key space of Zenoh dedicated to administering a Zenoh router and its plugins.
+It is accessible via regular GET/PUT on Zenoh, under the @/router/<router-id>
prefix, where
<router-id>
is the UUID of a Zenoh router.
When using the REST API, you can replace the <router-id>
with the local
keyword,
meaning the operation addresses the Zenoh router the HTTP client is connected to.
For instance, the following keys can be used:
@/router/<router-id>
(read-only):@/router/<router-id>/config/**
(write-only):Some plugins may extend the admin space, such as Storages, which will add the following keys:
@/router/<router-id>/status/plugins/storage_manager/volumes/<volume-name>
(read-only):@/router/<router-id>/status/plugins/storage_manager/storages/<storage-name>
(read-only):