Package: libzenohc
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 10507
Depends: libc6:arm64 (>= 2.31)
Filename: 0.7.2-rc/libzenohc_0.7.2-rc_arm64.deb
Size: 2816216
MD5sum: d11b83fa536bad8a18ba469f8386f42b
SHA1: 80e43e5cafed6bc74ca49513ab806b59b129dc0c
SHA256: f749c6698cdb430c6c09cfe54063f2c4f46c3a4ded4db89069e77b001220114b
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 10775
Depends: libc6:armel (>= 2.31)
Filename: 0.7.2-rc/libzenohc_0.7.2-rc_armel.deb
Size: 2923264
MD5sum: d6abccfdad6cbbe863f8961dd54bfce7
SHA1: 67ba2b1afb722ba181a064fd2499a3c70d4fdac0
SHA256: ae1637059dc3f95d0493d01ec80588393ee458745ed8ddee0b9320e3acce6400
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 10586
Depends: libc6:armhf (>= 2.31)
Filename: 0.7.2-rc/libzenohc_0.7.2-rc_armhf.deb
Size: 2913164
MD5sum: bcbc4eda37351e07f1dfa1010f7c2c93
SHA1: 00cce64b75eb7120fb0615a5cc82b3ffb5839493
SHA256: baacd7f8a0d649fa0c20ed2e75b00db294016174ac1dc99b6b3e023903a9859d
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 11765
Depends: libc6 (>= 2.28)
Filename: 0.7.2-rc/libzenohc_0.7.2-rc_amd64.deb
Size: 3151416
MD5sum: 0984daa69a3f38f3ab10ccf2d64e1202
SHA1: 7b428027caa9bdc54c40c735fd82ad5340796fdd
SHA256: d7d97d03a6e1b227f6f4c16d364c28e0eb45d305ab779c64f8b735a3f609ce90
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc-dev
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 125
Depends: libzenohc (=0.7.0~dev)
Filename: 0.7.2-rc/libzenohc-dev_0.7.2-rc_amd64.deb
Size: 26680
MD5sum: dc15a22cc6807d526bb9d8f5f0c99c5e
SHA1: b64fa908e041d78a8a29418fea4c08d565833e1c
SHA256: 099405dace93abc922e0fac117c36fbd42d4a6b10ad65bdb3be236ace853147e
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc-dev
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 125
Depends: libzenohc (=0.7.0~dev)
Filename: 0.7.2-rc/libzenohc-dev_0.7.2-rc_armhf.deb
Size: 26680
MD5sum: b4ec56fe77bba0c05ed13bdf67d142cc
SHA1: fcfb0afa7888b7bb23afd76bd6255fbf5c385690
SHA256: 4805aaa7cfd789624744a083ac09f80ff0e1e35ccf67371b164ff46eed0a1fe4
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc-dev
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 125
Depends: libzenohc (=0.7.0~dev)
Filename: 0.7.2-rc/libzenohc-dev_0.7.2-rc_armel.deb
Size: 26668
MD5sum: c22dc2395a4ce6a9b5096ce50b070c66
SHA1: c20d2afc2f541f49984726a85fc69e9116eb6933
SHA256: 21f01a84c9f21e66054a56253cddaa0c510f4c667110a32d5f8ce65c5b0a49bf
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohc-dev
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 125
Depends: libzenohc (=0.7.0~dev)
Filename: 0.7.2-rc/libzenohc-dev_0.7.2-rc_arm64.deb
Size: 26668
MD5sum: 44ce331079af54ee11eb8247f0106763
SHA1: 9ec2933d4394ba7ef397f55a2df516bd03d06ac0
SHA256: 7d3f95b0162fcdaf910b9980705a5bb269ad3e04faf18a1623f4c3a40fdbe1dd
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The Zenoh C API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-c/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-c/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-c/badge/?version=latest)](https://zenoh-c.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # C API
 .
 This repository provides a C binding based on the main [Zenoh implementation
 written in Rust](https://github.com/eclipse-zenoh/zenoh).
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 1. Make sure that [Rust](https://www.rust-lang.org) is available on your
 platform.
     Please check [here](https://www.rust-lang.org/tools/install) to learn how
 to install it.
 .
 2. Clone the [source] with `git`:
 .
    ```bash
    git clone https://github.com/eclipse-zenoh/zenoh-c.git
    ```
 .
 [source]: https://github.com/eclipse-zenoh/zenoh-c
 .
 3. Build:
 .
   Good CMake practice is to perform build outside of source directory, leaving
 source tree untouched. The examples below demonstrates this mode of building.
 On the other hand VScode by default creates build directory named 'build'
 inside source tree. In this case build script sligthly changes its behavior.
 See more about it in section 'VScode'.
 .
   By default build configuration is set to `Release`, it's not necessary to add
 `-DCMAKE_BUILD_TYPE=Release` option on configuration step. But if your platform
 uses multi-config generator by default (this is the case on Windows), you may
 need to add option `--config Release` on build step. See more in CMake
 [build-configurations] documenation. Option`--config Release` is skipped in
 further examples for brewity. It's actually necessary for [Visual Studio
 generators] only. For [Ninja Multi-Config] the build script is able to select
 `Release` as the default configuration.
 .
   ```bash
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c
   $ cmake --build . --config Release
   ```
 .
   The generator to use is selected with option `-G`. If Ninja is installed on
 your system, adding `-GNinja` to `cmake` command can greatly speed up the build
 time:
 .
   ```bash
   $ cmake ../zenoh-c -GNinja
   $ cmake --build .
    ```
 .
 [build-configurations]:
 https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#build-configurations
 [Visual Studio generators]:
 https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id14
 [Ninja]: https://cmake.org/cmake/help/latest/generator/Ninja.html
 [Ninja Multi-Config]:
 https://cmake.org/cmake/help/latest/generator/Ninja%20Multi-Config.html
 .
 3. Install:
 .
   To install zenoh-c library into system just build target `install`. You need
 root privileges to do it, as the default install location is `/usr/local`.
 .
   ```bash
   $ cmake --build . --target install
   ```
 .
   If you want to install zenoh-c libraries locally, you can set the
 installation directory with `CMAKE_INSTALL_PREFIX`
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
   $ cmake --build . --target install
   ```
 .
   By default only dynamic library is installed. Set
 `ZENOHC_INSTALL_STATIC_LIBRARY` variable to install static library also:
 .
   ```bash
   $ cmake ../zenoh-c -DCMAKE_INSTALL_PREFIX=~/.local
 -DZENOHC_INSTALL_STATIC_LIBRARY=TRUE
   $ cmake --build . --target install
   ```
 .
   The result of installation is the header files in `include` directory, the
 library files in `lib` directory and cmake package configuration files for
 package `zenohc` in `lib/cmake` directory. The library later can be loaded with
 CMake command `find_package(zenohc)`.
   Link to targets `zenohc::lib` for dynamic library and `zenohc::static` for
 static one in your CMakeLists.txt configuration file.
 .
   For `Debug` configuration the library package `zenohc_debug` is installed
 side-by-side with release `zenohc` library. Suffix `d` is added to names of
 library files (libzenohc**d**.so).
 .
 4. VScode
 .
   When zenoh-c project is opened in VSCode the build directory is set to
 `build` inside source tree (this is default behavior of Microsoft [CMake
 Tools]). The project build script detects this situation. In this case it
 places build files in `target` directory and `Cargo.toml` file (which is
 generated from `Cargo.toml.in`) into the root of source tree, as the rust
 developers used to and as the rust build tools expects by default. This
 behavior also can be explicitly enabled by setting
 `ZENOHC_BUILD_IN_SOURCE_TREE` variable to `TRUE`.
 .
 [CMake Tools]:
 https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools
 .
 ## Building the Examples
 .
   The examples can be built in two ways. One is to select `examples` as a build
 target of zenoh-c project (assuming here that the current directory is
 side-by-side with zenoh-c directory):
 .
   ```bash
   $ cmake ../zenoh-c
   $ cmake --build . --target examples
   ```
 .
   You may also use `--target <example_name>` if you wish to only build a
 specific example.
 .
   All build artifacts will be in the `target/release/examples` directory in
 this case.
 .
   Second way is to directly build `examples` as a root project:
 .
   ```bash
   $ cmake ../zenoh-c/examples
   $ cmake --build .
   ```
 .
   In this case the examples executables will be built in the current directory.
 .
   As a root project the `examples` project links `zenoh-c` with CMake's
 [add_subdirectory] command by default. There are also other ways to link
 `zenoh-c` - with [find_package] or [FetchContent]:
 .
 [add_subdirectory]:
 https://cmake.org/cmake/help/latest/command/add_subdirectory.html
 [find_package]: https://cmake.org/cmake/help/latest/command/find_package.html
 [FetchContent]: https://cmake.org/cmake/help/latest/module/FetchContent.html
 .
   Link with `zenoh-c` installed into default location in the system (with
 [find_package]):
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
   ```
 .
   Link with `zenoh-c` installed in `~/.local` directory:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=PACKAGE
 -DCMAKE_INSTALL_PREFIX=~/.local
   ```
 .
   Download specific `zenoh-c` version from git with [FetchContent]:
 .
   ```bash
   $ cmake ../zenoh-c/examples -DZENOHC_SOURCE=GIT_URL -DZENOHC_GIT_TAG=0.8.0-rc
   ```
 .
   See also `configure_include_project` function in [helpers.cmake] for more
 information
 .
 [helpers.cmake]: cmake/helpers.cmake
 .
 ## Running the Examples
 .
 ### Basic Pub/Sub Example
 ```bash
 $ ./target/release/examples/z_sub
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub
 ```
 .
 ### Queryable and Query Example
 ```bash
 $ ./target/release/examples/z_queryable
 ```
 .
 ```bash
 $ ./target/release/examples/z_get
 ```
 .
 ## Running the Throughput Examples
 ```bash
 $ ./target/release/examples/z_sub_thgr
 ```
 .
 ```bash
 $ ./target/release/examples/z_pub_thgr
 ```
 .
 ## API conventions
 Many of the types exposed by the `zenoh-c` API are types for which destruction
 is necessary. To help you spot these types, we named them with the convention
 that  any destructible type must start by `z_owned`.
 .
 For maximum performance, we try to make as few copies as possible. Sometimes,
 this implies moving data that you `z_owned`. Any function that takes a
 non-const pointer to a `z_owned` type will perform its destruction. To make
 this pattern more obvious, we encourage you to use the `z_move` macro instead
 of a simple `&` to create these pointers. Rest assured that all `z_owned` types
 are double-free safe, and that you may check whether any `z_owned_X_t` typed
 value is still valid by using `z_X_check(&val)`, or the `z_check(val)` macro if
 you're using C11.
 .
 We hope this convention will help you streamline your memory-safe usage of
 zenoh, as following it should make looking for leaks trivial: simply search for
 paths where a value of a `z_owned` type hasn't been passed to a function using
 `z_move`.
 .
 Functions that simply need to borrow your data will instead take values of the
 associated `z_X_t` type. You may construct them using `z_X_loan(&val)` (or the
 `z_loan(val)` generic macro with C11).
 .
 Note that some `z_X_t` typed values can be constructed without needing to
 `z_borrow` their owned variants. This allows you to reduce the amount of copies
 realized in your program.
 .
 The examples have been written with C11 in mind, using the conventions we
 encourage you to follow.
 .
 Finally, we strongly advise that you refrain from using structure field that
 starts with `_`:
 * We try to maintain a common API between `zenoh-c` and
 [`zenoh-pico`](https://github.com/eclipse-zenoh/zenoh-pico), such that porting
 code from one to the other is, ideally, trivial. However, some types must have
 distinct representations in either library, meaning that using these
 representations explicitly will get you in trouble when porting.
 * We reserve the right to change the memory layout of any type which has
 `_`-prefixed fields, so trying to use them might cause your code to break on
 updates.
 .
 ## Logging
 By default, zenoh-c enables Zenoh's logging library upon using the `z_open` or
 `z_scout` functions. This behaviour can be disabled by adding
 `-DDISABLE_LOGGER_AUTOINIT:bool=true` to the `cmake` configuration command. The
 logger may then be manually re-enabled with the `zc_init_logger` function.
 .
 ## Cross-Compilation
 * The following alternative options have been introduced to facilitate
 cross-compilation.
 > :warning: **WARNING** :warning: : Perhaps aditional efforts are neccesary,
 that will depend of your enviroment.
 .
 - `-DZENOHC_CARGO_CHANNEL=nightly|beta|stable`: refers to a specific rust
 toolchain release [`rust-channels`]
 https://rust-lang.github.io/rustup/concepts/channels.html
 - `-DZENOHC_CARGO_FLAGS`: several optional flags can be used for compilation.
 [`cargo flags`] https://doc.rust-lang.org/cargo/commands/cargo-build.html
 - `-DZENOHC_CUSTOM_TARGET`: specifies a crosscompilation target. Currently rust
 support several Tire-1, Tire-2 and Tire-3 targets [`targets`]
 https://doc.rust-lang.org/nightly/rustc/platform-support.html. But keep in mind
 that zenoh-c only have support for following targets:
 `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`,
 `arm-unknown-linux-gnueabi`
 .
 Lets put all together in an example:
 Assuming you want to crosscompile for aarch64-unknown-linux-gnu.
 .
 1. install required packages
   - `sudo apt install gcc-aarch64-linux-gnu`
 2. *(Only if you use `nightly` )
   - `rustup component add rust-src --toolchain nightly`
 3. Compile Zenoh-C. Assume that it's in 'zenoh-c' directory. Notice that build
 in this sample is performed outside of source directory
   ```bash
   $ export RUSTFLAGS="-Clinker=aarch64-linux-gnu-gcc -Car=aarch64-linux-gnu-ar"
   $ mkdir -p build && cd build
   $ cmake ../zenoh-c  -DZENOHC_CARGO_CHANNEL=nightly
 -DZENOHC_CARGO_FLAGS="-Zbuild-std=std,panic_abort"
 -DZENOHC_CUSTOM_TARGET="aarch64-unknown-linux-gnu"
 -DCMAKE_INSTALL_PREFIX=../aarch64/stage
   $ cmake --build . --target install
   ```
 Additionaly you can use `RUSTFLAGS` enviroment variable for lead the
 compilation.
 .
 -
 .
 .
 If all goes right the building files will be located at:
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
 and release files will be located at
 `/path/to/zenoh-c/target/aarch64-unknown-linux-gnu/release`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-c
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-c

Package: libzenohpico
Version: 0.7.20230606dev
Architecture: armhf
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 267
Depends: libc6 (>=2.12)
Filename: 0.7.2-rc/libzenohpico_0.7.20230606dev_armhf.deb
Size: 52564
MD5sum: 5dc43bc456212539457b802440f65019
SHA1: accdf6369caab350b364fe43bff3539e29056b5b
SHA256: 98cda78734f82318b4e07bb217656490eb429a4c2f2032f22cb3af870c45d43a
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices

Package: libzenohpico
Version: 0.7.20230606dev
Architecture: mips
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 353
Depends: libc6 (>=2.12)
Filename: 0.7.2-rc/libzenohpico_0.7.20230606dev_mips.deb
Size: 61672
MD5sum: 38f9f3abd1aed580d40b5b6be1337f27
SHA1: a9a6288b941379df042f7a0b66bf215c7b1634d9
SHA256: cdba744b1ce8409b7732fe70f1c2be6431b07c8e69319dcf6528a00f0b485da4
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices

Package: libzenohpico
Version: 0.7.20230606dev
Architecture: arm64
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 417
Depends: libc6 (>=2.12)
Filename: 0.7.2-rc/libzenohpico_0.7.20230606dev_arm64.deb
Size: 66752
MD5sum: 449ce2d89aeda0a2251edd977365eca8
SHA1: bb85d451b03bf131fcac9ddc62dd18860db5b6c4
SHA256: 8eb5ca1ecdf413ad87013d59a4a834707512e850c15431b9b2a8a3be01b620f2
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices

Package: libzenohpico
Version: 0.7.20230606dev
Architecture: arm
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 267
Depends: libc6 (>=2.12)
Filename: 0.7.2-rc/libzenohpico_0.7.20230606dev_arm.deb
Size: 52332
MD5sum: c84a85c8a64b5ade76cfeb84f740a6b1
SHA1: d0f9c6bbf29469708e27996cbecf49bb6ebc630c
SHA256: 46bc311602d09d7179abe31958e0ddd5952a9e65b4ca99c155d7cfdfd5f197a0
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices

Package: libzenohpico
Version: 0.7.20230606dev
Architecture: amd64
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 424
Depends: libc6 (>=2.12)
Filename: 0.7.2-rc/libzenohpico_0.7.20230606dev_amd64.deb
Size: 72884
MD5sum: 899a42c7d38f26c2e8f4b800ca73ef2a
SHA1: 93d0ae1e41e760cfb2c40838ad1fd4368bbacaae
SHA256: 304eaed714f96f02deb9c17a3b6305fbd4a4cd3bc2581415cc4750e4b4743889
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices

Package: libzenohpico
Version: 0.7.20230606dev
Architecture: i386
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 398
Depends: libc6 (>=2.12)
Filename: 0.7.2-rc/libzenohpico_0.7.20230606dev_i386.deb
Size: 83808
MD5sum: 971184d1bb3154769b9ea6e2f0241238
SHA1: 27737e1e242a4849517650bcc9aa0d48fd822574
SHA256: b6e38de37053ddb050bc1ae2c2897a3a56ab24d8eed5863b68b4168bb7b6b1f3
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices

Package: libzenohpico-dev
Version: 0.7.20230606dev
Architecture: arm
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 380
Depends: libzenohpico (=0.7.20230606dev)
Filename: 0.7.2-rc/libzenohpico-dev_0.7.20230606dev_arm.deb
Size: 42072
MD5sum: 7c1e011b5de400c7dd38966af2a0dd32
SHA1: a2233b3ac4198e67fdc428ca6d9c1d4f79c6b47a
SHA256: 7533d21fdbcaf4211a3dabd10ef4d336ba1a7ffd4424de02547fcba4a79db0e9
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices - devel files

Package: libzenohpico-dev
Version: 0.7.20230606dev
Architecture: arm64
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 380
Depends: libzenohpico (=0.7.20230606dev)
Filename: 0.7.2-rc/libzenohpico-dev_0.7.20230606dev_arm64.deb
Size: 42092
MD5sum: 5bc983cdfea83537f4c3c3fb2e7f10a2
SHA1: 4749f7b10a3f2e2d31b9e8a28498ec1840f71b5e
SHA256: 63cd56d99ac0b070c7a75a7c08afa9338847210a86390a612a91e300699ce1b6
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices - devel files

Package: libzenohpico-dev
Version: 0.7.20230606dev
Architecture: i386
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 380
Depends: libzenohpico (=0.7.20230606dev)
Filename: 0.7.2-rc/libzenohpico-dev_0.7.20230606dev_i386.deb
Size: 42080
MD5sum: ad971af78950a8b67bb8fa68ad26569d
SHA1: 93afd7b9b365e56123aad6effa0db4c6a3c026d3
SHA256: 9e01a9d0bd52562917474096bb94fee793d8b563f4d489938f6f9c1e76e00a83
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices - devel files

Package: libzenohpico-dev
Version: 0.7.20230606dev
Architecture: mips
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 380
Depends: libzenohpico (=0.7.20230606dev)
Filename: 0.7.2-rc/libzenohpico-dev_0.7.20230606dev_mips.deb
Size: 42072
MD5sum: 0aedb3445cb8c8d1c8d7e5a77baccef6
SHA1: 6443e19a2f746886deb17afa9730b66a524dd237
SHA256: 7f341f4c219a01b0fabb045cc5d05d957df604760903b191c91505ecc9e643bf
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices - devel files

Package: libzenohpico-dev
Version: 0.7.20230606dev
Architecture: armhf
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 380
Depends: libzenohpico (=0.7.20230606dev)
Filename: 0.7.2-rc/libzenohpico-dev_0.7.20230606dev_armhf.deb
Size: 42072
MD5sum: fcf8b0b4ba23076aaa588d5e0ee4be95
SHA1: 410ceca845e421dc0ef0cbc900371444eb5e1c3d
SHA256: 801afb0fc5d0eeb5878a91f7a80914850487e7050319ebe12d51ed9c0fbde123
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices - devel files

Package: libzenohpico-dev
Version: 0.7.20230606dev
Architecture: amd64
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 380
Depends: libzenohpico (=0.7.20230606dev)
Filename: 0.7.2-rc/libzenohpico-dev_0.7.20230606dev_amd64.deb
Size: 42088
MD5sum: 7cbadfd0402a341bdecbc2374c5bddfb
SHA1: 31331c61bd7a36bac521de4ead07440218974d2e
SHA256: c80eec21c0ed82bf28bb00ba1dd95f69c4f1163fc9ca4c44e2549c3605c83648
Section: devel
Priority: optional
Description: The C client library for Eclipse zenoh targeting pico devices - devel files

Package: zenoh
Version: 0.7.2-rc
Architecture: armhf
Essential: no
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 1024
Depends: zenohd (=0.7.2-rc), zenoh-plugin-rest (=0.7.2-rc), zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh_0.7.2-rc_armhf.deb
Size: 832
MD5sum: 2c9045ca19ca1876c4070c988a88172d
SHA1: f03002fa62da6f3c5777d92f1a5e70736b50f1c6
SHA256: 3e6c216556d380764b71481167bdec04c45081149149ccb49b7d80723f38376a
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh top-level package
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh
Version: 0.7.2-rc
Architecture: armel
Essential: no
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 1024
Depends: zenohd (=0.7.2-rc), zenoh-plugin-rest (=0.7.2-rc), zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh_0.7.2-rc_armel.deb
Size: 832
MD5sum: 254a2a4118d20276e575e19f02ed4342
SHA1: 345cdc840e0bc11cab8e4cd9ec957038572ff734
SHA256: 8e6cd9e303c92b2f23d3d0b1c5d9dcd5d771ab9699fadf88208f3053a06e453d
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh top-level package
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh
Version: 0.7.2-rc
Architecture: amd64
Essential: no
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 1024
Depends: zenohd (=0.7.2-rc), zenoh-plugin-rest (=0.7.2-rc), zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh_0.7.2-rc_amd64.deb
Size: 832
MD5sum: 44b1658a1493a977af84fbf60fd981c7
SHA1: e8b88b6b4ec1c667665e62ceabe0256623bcb865
SHA256: 83f2e40b454aa3140a0bd2df13d64cbcbdfaaff69425f72bec6beba26b7685fe
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh top-level package
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh
Version: 0.7.2-rc
Architecture: arm64
Essential: no
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 1024
Depends: zenohd (=0.7.2-rc), zenoh-plugin-rest (=0.7.2-rc), zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh_0.7.2-rc_arm64.deb
Size: 832
MD5sum: bb6143c728168dc97f96c2d78490e52f
SHA1: fb0231ac32796da3b1fa91e7c3220bf0c0f8d608
SHA256: 13db8d1a92604a87b715a4741aa7100d846ea9dd8aeb00f64c114a2fba1e47bf
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh top-level package
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-backend-filesystem
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 9542
Depends: zenoh-plugin-storage-manager  (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-filesystem_0.7.2-rc_amd64.deb
Size: 2923076
MD5sum: 8bc530d7c51d8966d759f63272474a7c
SHA1: ebb146e566932470794544819d749e23220d402c
SHA256: 07b5964ef3adaff40170c1eee99bb806744933db3e042b3a6e9c06116f1841f7
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using the file system
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # File system backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on the host's file system to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_fs`**.
 .
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the `zenoh_backend_fs`
 library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_FS_ROOT` environment variable to the directory
 where you want the files to be stored (or exposed from).
    If you don't declare it, the `~/.zenoh/zenoh_backend_fs` directory will be
 used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storage-manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "fs" volume (the "zenoh_backend_fs" backend
 library will be loaded at startup)
             fs: {},
           },
           storages: {
             // configuration of a "demo" storage using the "fs" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to file path
               // this argument is optional.
               strip_prefix: "demo/example",
               volume: {
                 id: "fs",
                 // the key/values will be stored as files within this directory
 (relative to ${ZENOH_BACKEND_FS_ROOT})
                 dir: "example"
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "fs" backend (the "zenoh_backend_fs" library will be loaded):
     `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/fs`
   - Add the "demo" storage using the "fs" backend:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example", volume: {id: "fs",
 dir:"example"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored under ${ZENOH_BACKEND_FS_ROOT}/example
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test the zenoh router in a Docker container:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_fs.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Also create a `./zenoh_filesystem/test` directory that will be used for the
 storage.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, and explore the resulting file in
 `./zenoh_filesystem/test`
 -->
 .
 -------------------------------
 ## Configuration
 ### Extra configuration for filesystem-backed volumes
 .
 Volumes using the `fs` backend don't need any extra configuration at the volume
 level. Any volume can use the `fs` backend by specifying the value `"fs"` for
 the `backend` configuration key. A volume named `fs` will automatically be
 backed by the `fs` backend if no other backend is specified.
 .
 -------------------------------
 ### Storage-level configuration for filesystem-backed volumes
 .
 Storages relying on a `fs` backed volume must/can specify additional
 configuration specific to that volume, as shown in the example
 [above](#setup-via-a-json5-configuration-file):
 - `dir` (**required**, string) : The directory that will be used to store data.
 .
 - `read_only` (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't write any
 file. `false` by default.
 .
 - `on_closure` (optional, string) : the strategy to use when the Storage is
 removed. There are 2 options:
   - `"do_nothing"`: the storage's directory remains untouched (this is the
 default behaviour)
   - `"delete_all"`: the storage's directory is deleted with all its content.
 .
 - `follow_links` (optional, boolean) : If set to `true` the storage will follow
 the symbolic links. The default value is `false`.
 .
 - `keep_mime_types` (optional, boolean) : When replying to a GET query with a
 file for which the zenoh encoding is not known, the storage guess its mime-type
 according to the file extension. If the mime-type doesn't correspond to a
 supported zenoh encoding, this option will drive the returned value:
    - `true` (default value): a [Custom
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Custom)
      is returned with the description set to the mime-type.
    - `false`: a [Raw
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Raw) with
      APP_OCTET_STREAM encoding is returned.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to file system
 Each **storage** will map to a directory with path:
 `${ZENOH_BACKEND_FS_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_FS_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_fs` will be
 used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to a file within the
 storage's directory where:
   * the file path will be
 `${ZENOH_BACKEND_FS_ROOT}/<dir>/<relative_zenoh_key>`, where
 `<relative_zenoh_key>`
     will be the zenoh key, stripped from the `"strip_prefix"` property
 specified at storage creation.
   * the content of the file will be the value written as a RawValue. I.e. the
 same bytes buffer that has been
     transported by zenoh. For UTF-8 compatible formats (StringUTF8, JSon,
 Integer, Float...) it means the file
     will be readable as a text format.
   * the encoding and the timestamp of the key/value will be stored in a RocksDB
 database stored in the storage directory.
 .
 ### Behaviour on deletion
 .
 On deletion of a key, the corresponding file is removed. An entry with deletion
 timestamp is inserted in the
 RocksDB database (to avoid re-insertion of points with an older timestamp in
 case of un-ordered messages).
 At regular interval, a task cleans-up the RocksDB database from entries with
 old timestamps that don't have a
 corresponding existing file.
 .
 ### Behaviour on GET
 .
 On GET operations, the storage searches for matching and existing files, and
 return their raw content as a reply.
 For each, the encoding and timestamp are retrieved from the RocksDB database.
 But if no entry is found in the
 database for a file (e.g. for files created without zenoh), the encoding is
 deduced from the file's extension
 (using [mime_guess](https://crates.io/crates/mime_guess)), and the timestamp is
 deduced from the file's
 modification time.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-filesystem/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-filesystem` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-filesystem
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-filesystem
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-filesystem

Package: zenoh-backend-filesystem
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 8394
Depends: zenoh-plugin-storage-manager  (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-filesystem_0.7.2-rc_arm64.deb
Size: 2538116
MD5sum: d38fe2cee469b811b980da43f4b46e95
SHA1: 11e2531a831d7538cec20465826fe90318967935
SHA256: 7d3e8846bb4d150bf234cead9d0d2e0b9a825e35c654fea13afbd4e473ce9206
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using the file system
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # File system backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on the host's file system to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_fs`**.
 .
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the `zenoh_backend_fs`
 library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_FS_ROOT` environment variable to the directory
 where you want the files to be stored (or exposed from).
    If you don't declare it, the `~/.zenoh/zenoh_backend_fs` directory will be
 used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storage-manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "fs" volume (the "zenoh_backend_fs" backend
 library will be loaded at startup)
             fs: {},
           },
           storages: {
             // configuration of a "demo" storage using the "fs" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to file path
               // this argument is optional.
               strip_prefix: "demo/example",
               volume: {
                 id: "fs",
                 // the key/values will be stored as files within this directory
 (relative to ${ZENOH_BACKEND_FS_ROOT})
                 dir: "example"
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "fs" backend (the "zenoh_backend_fs" library will be loaded):
     `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/fs`
   - Add the "demo" storage using the "fs" backend:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example", volume: {id: "fs",
 dir:"example"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored under ${ZENOH_BACKEND_FS_ROOT}/example
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test the zenoh router in a Docker container:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_fs.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Also create a `./zenoh_filesystem/test` directory that will be used for the
 storage.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, and explore the resulting file in
 `./zenoh_filesystem/test`
 -->
 .
 -------------------------------
 ## Configuration
 ### Extra configuration for filesystem-backed volumes
 .
 Volumes using the `fs` backend don't need any extra configuration at the volume
 level. Any volume can use the `fs` backend by specifying the value `"fs"` for
 the `backend` configuration key. A volume named `fs` will automatically be
 backed by the `fs` backend if no other backend is specified.
 .
 -------------------------------
 ### Storage-level configuration for filesystem-backed volumes
 .
 Storages relying on a `fs` backed volume must/can specify additional
 configuration specific to that volume, as shown in the example
 [above](#setup-via-a-json5-configuration-file):
 - `dir` (**required**, string) : The directory that will be used to store data.
 .
 - `read_only` (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't write any
 file. `false` by default.
 .
 - `on_closure` (optional, string) : the strategy to use when the Storage is
 removed. There are 2 options:
   - `"do_nothing"`: the storage's directory remains untouched (this is the
 default behaviour)
   - `"delete_all"`: the storage's directory is deleted with all its content.
 .
 - `follow_links` (optional, boolean) : If set to `true` the storage will follow
 the symbolic links. The default value is `false`.
 .
 - `keep_mime_types` (optional, boolean) : When replying to a GET query with a
 file for which the zenoh encoding is not known, the storage guess its mime-type
 according to the file extension. If the mime-type doesn't correspond to a
 supported zenoh encoding, this option will drive the returned value:
    - `true` (default value): a [Custom
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Custom)
      is returned with the description set to the mime-type.
    - `false`: a [Raw
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Raw) with
      APP_OCTET_STREAM encoding is returned.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to file system
 Each **storage** will map to a directory with path:
 `${ZENOH_BACKEND_FS_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_FS_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_fs` will be
 used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to a file within the
 storage's directory where:
   * the file path will be
 `${ZENOH_BACKEND_FS_ROOT}/<dir>/<relative_zenoh_key>`, where
 `<relative_zenoh_key>`
     will be the zenoh key, stripped from the `"strip_prefix"` property
 specified at storage creation.
   * the content of the file will be the value written as a RawValue. I.e. the
 same bytes buffer that has been
     transported by zenoh. For UTF-8 compatible formats (StringUTF8, JSon,
 Integer, Float...) it means the file
     will be readable as a text format.
   * the encoding and the timestamp of the key/value will be stored in a RocksDB
 database stored in the storage directory.
 .
 ### Behaviour on deletion
 .
 On deletion of a key, the corresponding file is removed. An entry with deletion
 timestamp is inserted in the
 RocksDB database (to avoid re-insertion of points with an older timestamp in
 case of un-ordered messages).
 At regular interval, a task cleans-up the RocksDB database from entries with
 old timestamps that don't have a
 corresponding existing file.
 .
 ### Behaviour on GET
 .
 On GET operations, the storage searches for matching and existing files, and
 return their raw content as a reply.
 For each, the encoding and timestamp are retrieved from the RocksDB database.
 But if no entry is found in the
 database for a file (e.g. for files created without zenoh), the encoding is
 deduced from the file's extension
 (using [mime_guess](https://crates.io/crates/mime_guess)), and the timestamp is
 deduced from the file's
 modification time.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-filesystem/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-filesystem` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-filesystem
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-filesystem
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-filesystem

Package: zenoh-backend-filesystem
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 6205
Depends: zenoh-plugin-storage-manager  (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-filesystem_0.7.2-rc_armhf.deb
Size: 2585672
MD5sum: 1e212d9f380401d1bed2f4ed64e4f91d
SHA1: 45c9a0cb89cb05a77d16b31abd7599033e71cd8c
SHA256: 3f940d634bc9aa8cb6d8e85201b0f6058ec85b2d443531c79824487c750e0dee
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using the file system
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # File system backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on the host's file system to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_fs`**.
 .
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the `zenoh_backend_fs`
 library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_FS_ROOT` environment variable to the directory
 where you want the files to be stored (or exposed from).
    If you don't declare it, the `~/.zenoh/zenoh_backend_fs` directory will be
 used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storage-manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "fs" volume (the "zenoh_backend_fs" backend
 library will be loaded at startup)
             fs: {},
           },
           storages: {
             // configuration of a "demo" storage using the "fs" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to file path
               // this argument is optional.
               strip_prefix: "demo/example",
               volume: {
                 id: "fs",
                 // the key/values will be stored as files within this directory
 (relative to ${ZENOH_BACKEND_FS_ROOT})
                 dir: "example"
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "fs" backend (the "zenoh_backend_fs" library will be loaded):
     `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/fs`
   - Add the "demo" storage using the "fs" backend:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example", volume: {id: "fs",
 dir:"example"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored under ${ZENOH_BACKEND_FS_ROOT}/example
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test the zenoh router in a Docker container:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_fs.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Also create a `./zenoh_filesystem/test` directory that will be used for the
 storage.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, and explore the resulting file in
 `./zenoh_filesystem/test`
 -->
 .
 -------------------------------
 ## Configuration
 ### Extra configuration for filesystem-backed volumes
 .
 Volumes using the `fs` backend don't need any extra configuration at the volume
 level. Any volume can use the `fs` backend by specifying the value `"fs"` for
 the `backend` configuration key. A volume named `fs` will automatically be
 backed by the `fs` backend if no other backend is specified.
 .
 -------------------------------
 ### Storage-level configuration for filesystem-backed volumes
 .
 Storages relying on a `fs` backed volume must/can specify additional
 configuration specific to that volume, as shown in the example
 [above](#setup-via-a-json5-configuration-file):
 - `dir` (**required**, string) : The directory that will be used to store data.
 .
 - `read_only` (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't write any
 file. `false` by default.
 .
 - `on_closure` (optional, string) : the strategy to use when the Storage is
 removed. There are 2 options:
   - `"do_nothing"`: the storage's directory remains untouched (this is the
 default behaviour)
   - `"delete_all"`: the storage's directory is deleted with all its content.
 .
 - `follow_links` (optional, boolean) : If set to `true` the storage will follow
 the symbolic links. The default value is `false`.
 .
 - `keep_mime_types` (optional, boolean) : When replying to a GET query with a
 file for which the zenoh encoding is not known, the storage guess its mime-type
 according to the file extension. If the mime-type doesn't correspond to a
 supported zenoh encoding, this option will drive the returned value:
    - `true` (default value): a [Custom
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Custom)
      is returned with the description set to the mime-type.
    - `false`: a [Raw
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Raw) with
      APP_OCTET_STREAM encoding is returned.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to file system
 Each **storage** will map to a directory with path:
 `${ZENOH_BACKEND_FS_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_FS_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_fs` will be
 used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to a file within the
 storage's directory where:
   * the file path will be
 `${ZENOH_BACKEND_FS_ROOT}/<dir>/<relative_zenoh_key>`, where
 `<relative_zenoh_key>`
     will be the zenoh key, stripped from the `"strip_prefix"` property
 specified at storage creation.
   * the content of the file will be the value written as a RawValue. I.e. the
 same bytes buffer that has been
     transported by zenoh. For UTF-8 compatible formats (StringUTF8, JSon,
 Integer, Float...) it means the file
     will be readable as a text format.
   * the encoding and the timestamp of the key/value will be stored in a RocksDB
 database stored in the storage directory.
 .
 ### Behaviour on deletion
 .
 On deletion of a key, the corresponding file is removed. An entry with deletion
 timestamp is inserted in the
 RocksDB database (to avoid re-insertion of points with an older timestamp in
 case of un-ordered messages).
 At regular interval, a task cleans-up the RocksDB database from entries with
 old timestamps that don't have a
 corresponding existing file.
 .
 ### Behaviour on GET
 .
 On GET operations, the storage searches for matching and existing files, and
 return their raw content as a reply.
 For each, the encoding and timestamp are retrieved from the RocksDB database.
 But if no entry is found in the
 database for a file (e.g. for files created without zenoh), the encoding is
 deduced from the file's extension
 (using [mime_guess](https://crates.io/crates/mime_guess)), and the timestamp is
 deduced from the file's
 modification time.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-filesystem/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-filesystem` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-filesystem
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-filesystem
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-filesystem

Package: zenoh-backend-filesystem
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 7957
Depends: zenoh-plugin-storage-manager  (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-filesystem_0.7.2-rc_armel.deb
Size: 2483564
MD5sum: a7812456ab6b1d422c0db9b858cabefb
SHA1: ccdf4e8b144bdc3586fdeceeaaa5a3075a28bcb1
SHA256: a090f08b07d9f2fcbf1a7d55e2278977a5d54728234f0e7e3d7c8578516e7d43
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using the file system
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # File system backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on the host's file system to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_fs`**.
 .
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the `zenoh_backend_fs`
 library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_FS_ROOT` environment variable to the directory
 where you want the files to be stored (or exposed from).
    If you don't declare it, the `~/.zenoh/zenoh_backend_fs` directory will be
 used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storage-manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "fs" volume (the "zenoh_backend_fs" backend
 library will be loaded at startup)
             fs: {},
           },
           storages: {
             // configuration of a "demo" storage using the "fs" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to file path
               // this argument is optional.
               strip_prefix: "demo/example",
               volume: {
                 id: "fs",
                 // the key/values will be stored as files within this directory
 (relative to ${ZENOH_BACKEND_FS_ROOT})
                 dir: "example"
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "fs" backend (the "zenoh_backend_fs" library will be loaded):
     `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/fs`
   - Add the "demo" storage using the "fs" backend:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example", volume: {id: "fs",
 dir:"example"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored under ${ZENOH_BACKEND_FS_ROOT}/example
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test the zenoh router in a Docker container:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-filesystem/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_fs.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Also create a `./zenoh_filesystem/test` directory that will be used for the
 storage.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, and explore the resulting file in
 `./zenoh_filesystem/test`
 -->
 .
 -------------------------------
 ## Configuration
 ### Extra configuration for filesystem-backed volumes
 .
 Volumes using the `fs` backend don't need any extra configuration at the volume
 level. Any volume can use the `fs` backend by specifying the value `"fs"` for
 the `backend` configuration key. A volume named `fs` will automatically be
 backed by the `fs` backend if no other backend is specified.
 .
 -------------------------------
 ### Storage-level configuration for filesystem-backed volumes
 .
 Storages relying on a `fs` backed volume must/can specify additional
 configuration specific to that volume, as shown in the example
 [above](#setup-via-a-json5-configuration-file):
 - `dir` (**required**, string) : The directory that will be used to store data.
 .
 - `read_only` (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't write any
 file. `false` by default.
 .
 - `on_closure` (optional, string) : the strategy to use when the Storage is
 removed. There are 2 options:
   - `"do_nothing"`: the storage's directory remains untouched (this is the
 default behaviour)
   - `"delete_all"`: the storage's directory is deleted with all its content.
 .
 - `follow_links` (optional, boolean) : If set to `true` the storage will follow
 the symbolic links. The default value is `false`.
 .
 - `keep_mime_types` (optional, boolean) : When replying to a GET query with a
 file for which the zenoh encoding is not known, the storage guess its mime-type
 according to the file extension. If the mime-type doesn't correspond to a
 supported zenoh encoding, this option will drive the returned value:
    - `true` (default value): a [Custom
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Custom)
      is returned with the description set to the mime-type.
    - `false`: a [Raw
 value](https://docs.rs/zenoh/latest/zenoh/enum.Value.html#variant.Raw) with
      APP_OCTET_STREAM encoding is returned.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to file system
 Each **storage** will map to a directory with path:
 `${ZENOH_BACKEND_FS_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_FS_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_fs` will be
 used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to a file within the
 storage's directory where:
   * the file path will be
 `${ZENOH_BACKEND_FS_ROOT}/<dir>/<relative_zenoh_key>`, where
 `<relative_zenoh_key>`
     will be the zenoh key, stripped from the `"strip_prefix"` property
 specified at storage creation.
   * the content of the file will be the value written as a RawValue. I.e. the
 same bytes buffer that has been
     transported by zenoh. For UTF-8 compatible formats (StringUTF8, JSon,
 Integer, Float...) it means the file
     will be readable as a text format.
   * the encoding and the timestamp of the key/value will be stored in a RocksDB
 database stored in the storage directory.
 .
 ### Behaviour on deletion
 .
 On deletion of a key, the corresponding file is removed. An entry with deletion
 timestamp is inserted in the
 RocksDB database (to avoid re-insertion of points with an older timestamp in
 case of un-ordered messages).
 At regular interval, a task cleans-up the RocksDB database from entries with
 old timestamps that don't have a
 corresponding existing file.
 .
 ### Behaviour on GET
 .
 On GET operations, the storage searches for matching and existing files, and
 return their raw content as a reply.
 For each, the encoding and timestamp are retrieved from the RocksDB database.
 But if no entry is found in the
 database for a file (e.g. for files created without zenoh), the encoding is
 deduced from the file's extension
 (using [mime_guess](https://crates.io/crates/mime_guess)), and the timestamp is
 deduced from the file's
 modification time.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-filesystem/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-filesystem` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-filesystem
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-filesystem
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-filesystem

Package: zenoh-backend-influxdb
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3880
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-influxdb_0.7.2-rc_armel.deb
Size: 1174892
MD5sum: 8d53678f3a67ab27424469af5ca499f6
SHA1: 9d978d4313667116c9b58f67a46e09df628c7795
SHA256: fcdb3238c2deab8564f3a18c899d521f9e63dc77c8b732a10f3ae4d99ceaf565
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using InfluxDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # InfluxDB backend
 .
 In Zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on an
 [InfluxDB](https://www.influxdata.com/products/influxdb/) server
 to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_influxdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 :warning: InfluxDB 2.x is not yet supported. InfluxDB 1.8 minimum is required.
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_influxdb` library file is available in `~/.zenoh/lib`.
  - You have an InfluxDB service running and listening on
 `http://localhost:8086`
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing for example:
     ```json5
     {
       plugins: {
         // configuration of "storage_manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "influxdb" volume (the
 "zenoh_backend_influxdb" backend library will be loaded at startup)
             influxdb: {
               // URL to the InfluxDB service
               url: "http://localhost:8086",
               private: {
                 // If needed: InfluxDB credentials, preferably admin for
 databases creation and drop
                 //username: "admin",
                 //password: "password"
               }
             }
           },
           storages: {
             // configuration of a "demo" storage using the "influxdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               // this option is optional
               strip_prefix: "demo/example",
               volume: {
                 id: "influxdb",
                 // the database name within InfluxDB
                 db: "zenoh_example",
                 // if the database doesn't exist, create it
                 create_db: true,
                 // strategy on storage closure
                 on_closure: "drop_db",
                 private: {
                   // If needed: InfluxDB credentials, with read/write
 privileges for the database
                   //username: "user",
                   //password: "password"
                 }
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "influxdb" volume (the "zenoh_backend_fs" library will be loaded),
 connected to InfluxDB service on http://localhost:8086:
     `curl -X PUT -H 'content-type:application/json' -d
 '{url:"http://localhost:8086"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/influxdb`
   - Add the "demo" storage using the "influxdb" volume:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",volume:{id:"influxdb",db:"zenoh_example",create_db:true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put some values at different time intervals
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-2" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-3" http://localhost:8000/demo/example/test
 .
 # Retrive them as a time serie where '_time=[..]' means "infinite time range"
 curl -g 'http://localhost:8000/demo/example/test?_time=[..]'
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test running both the zenoh router and the InfluxDB
 service in Docker containers:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_influxdb.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, replacing the URL to InfluxDB with
 `http://influxdb:8086` (instead of localhost)
 -->
 .
 -------------------------------
 ## Volume configuration
 InfluxDB-backed volumes need some configuration to work:
 .
 - **`"url"`** (**required**) : a URL to the InfluxDB service. Example:
 `http://localhost:8086`
 .
 - **`"username"`** (optional) : an [InfluxDB
 admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#admin-users)
 user name. It will be used for creation of databases, granting read/write
 privileges of databases mapped to storages and dropping of databases and
 measurements.
 .
 - **`"password"`** (optional) : the admin user's password.
 .
 Both `username` and `password` should be hidden behind a `private` gate, as
 shown in the example [above](#setup-via-a-json5-configuration-file). In
 general, if you wish for a part of the configuration to be hidden when
 configuration is queried, you should hide it behind a `private` gate.
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a `influxdb` backed volume may have additional
 configuration through the `volume` section:
 - **`"db"`** (optional, string) : the InfluxDB database name the storage will
 map into. If not specified, a random name will be generated, and the
 corresponding database will be created (even if `"create_db"` is not set).
 .
 - **`"create_db"`** (optional, boolean) : create the InfluxDB database if not
 already existing.
   By default the database is not created, unless `"db"` property is not
 specified.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 3 options:
   - *unset* or `"do_nothing"`: the database remains untouched (this is the
 default behaviour)
   - `"drop_db"`: the database is dropped (i.e. removed)
   - `"drop_series"`: all the series (measurements) are dropped and the database
 remains empty.
 .
 - **`"username"`** (optional, string) : an InfluxDB user name (usually
 [non-admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#non-admin-users)).
 It will be used to read/write points in the database on GET/PUT/DELETE zenoh
 operations.
 .
 - **`"password"`** (optional, string) : the user's password.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to InfluxDB concepts
 Each **storage** will map to an InfluxDB **database**.
 Each **key** to store will map to an InfluxDB
 [**measurement**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#measurement)
 named with the key stripped from the `"strip_prefix"` property (see below).
 Each **key/value** put into the storage will map to an InfluxDB
 [**point**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#point)
 reusing the timestamp set by zenoh
 (but with a precision of nanoseconds). The fileds and tags of the point is are
 the following:
  - `"kind"` tag: the zenoh change kind (`"PUT"` for a value that have been put,
 or `"DEL"` to mark the deletion of the key)
  - `"timestamp"` field: the original zenoh timestamp
  - `"encoding"` field: the value's encoding flag
  - `"base64"` field: a boolean indicating if the value is encoded in base64
  - `"value"`field: the value as a string, possibly encoded in base64 for binary
 values.
 .
 ### Behaviour on deletion
 On deletion of a key, all points with a timestamp before the deletion message
 are deleted.
 A point with `"kind"="DEL`" is inserted (to avoid re-insertion of points with
 an older timestamp in case of un-ordered messages).
 After a delay (5 seconds), the measurement corresponding to the deleted key is
 dropped if it still contains no points.
 .
 ### Behaviour on GET
 On GET operations, by default the storage returns only the latest point for
 each key/measurement.
 This is to be coherent with other backends technologies that only store 1 value
 per-key.
 If you want to get time-series as a result of a GET operation, you need to
 specify a time range via
 the `"_time"`argument in your
 [Selector](https://github.com/eclipse-zenoh/roadmap/tree/main/rfcs/ALL/Selectors).
 .
 Examples of selectors:
 ```bash
   # get the complete time-series
   /demo/example/**?_time=[..]
 .
   # get points within a fixed date interval
   /demo/example/influxdb/**?_time=[2020-01-01T00:00:00Z..2020-01-02T12:00:00.000000000Z]
 .
   # get points within a relative date interval
   /demo/example/influxdb/**?_time=[now(-2d)..now(-1d)]
 ```
 .
 See the [`"_time"`
 RFC](https://github.com/eclipse-zenoh/roadmap/blob/main/rfcs/ALL/Selectors/_time.md)
 for a complete description of the time range format
 .
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-influxdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-influxdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-influxdb
 ```
 .
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-influxdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-influxdb

Package: zenoh-backend-influxdb
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3796
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-influxdb_0.7.2-rc_armhf.deb
Size: 1170584
MD5sum: b653095addbd72d371118fd542fe3028
SHA1: 33f39c819e2f42311414f43ceec53f68e56cb0b4
SHA256: f134c229b181dc969ac4658828e01f8829818af28a57ff1f4d98b408d062adfd
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using InfluxDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # InfluxDB backend
 .
 In Zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on an
 [InfluxDB](https://www.influxdata.com/products/influxdb/) server
 to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_influxdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 :warning: InfluxDB 2.x is not yet supported. InfluxDB 1.8 minimum is required.
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_influxdb` library file is available in `~/.zenoh/lib`.
  - You have an InfluxDB service running and listening on
 `http://localhost:8086`
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing for example:
     ```json5
     {
       plugins: {
         // configuration of "storage_manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "influxdb" volume (the
 "zenoh_backend_influxdb" backend library will be loaded at startup)
             influxdb: {
               // URL to the InfluxDB service
               url: "http://localhost:8086",
               private: {
                 // If needed: InfluxDB credentials, preferably admin for
 databases creation and drop
                 //username: "admin",
                 //password: "password"
               }
             }
           },
           storages: {
             // configuration of a "demo" storage using the "influxdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               // this option is optional
               strip_prefix: "demo/example",
               volume: {
                 id: "influxdb",
                 // the database name within InfluxDB
                 db: "zenoh_example",
                 // if the database doesn't exist, create it
                 create_db: true,
                 // strategy on storage closure
                 on_closure: "drop_db",
                 private: {
                   // If needed: InfluxDB credentials, with read/write
 privileges for the database
                   //username: "user",
                   //password: "password"
                 }
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "influxdb" volume (the "zenoh_backend_fs" library will be loaded),
 connected to InfluxDB service on http://localhost:8086:
     `curl -X PUT -H 'content-type:application/json' -d
 '{url:"http://localhost:8086"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/influxdb`
   - Add the "demo" storage using the "influxdb" volume:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",volume:{id:"influxdb",db:"zenoh_example",create_db:true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put some values at different time intervals
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-2" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-3" http://localhost:8000/demo/example/test
 .
 # Retrive them as a time serie where '_time=[..]' means "infinite time range"
 curl -g 'http://localhost:8000/demo/example/test?_time=[..]'
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test running both the zenoh router and the InfluxDB
 service in Docker containers:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_influxdb.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, replacing the URL to InfluxDB with
 `http://influxdb:8086` (instead of localhost)
 -->
 .
 -------------------------------
 ## Volume configuration
 InfluxDB-backed volumes need some configuration to work:
 .
 - **`"url"`** (**required**) : a URL to the InfluxDB service. Example:
 `http://localhost:8086`
 .
 - **`"username"`** (optional) : an [InfluxDB
 admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#admin-users)
 user name. It will be used for creation of databases, granting read/write
 privileges of databases mapped to storages and dropping of databases and
 measurements.
 .
 - **`"password"`** (optional) : the admin user's password.
 .
 Both `username` and `password` should be hidden behind a `private` gate, as
 shown in the example [above](#setup-via-a-json5-configuration-file). In
 general, if you wish for a part of the configuration to be hidden when
 configuration is queried, you should hide it behind a `private` gate.
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a `influxdb` backed volume may have additional
 configuration through the `volume` section:
 - **`"db"`** (optional, string) : the InfluxDB database name the storage will
 map into. If not specified, a random name will be generated, and the
 corresponding database will be created (even if `"create_db"` is not set).
 .
 - **`"create_db"`** (optional, boolean) : create the InfluxDB database if not
 already existing.
   By default the database is not created, unless `"db"` property is not
 specified.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 3 options:
   - *unset* or `"do_nothing"`: the database remains untouched (this is the
 default behaviour)
   - `"drop_db"`: the database is dropped (i.e. removed)
   - `"drop_series"`: all the series (measurements) are dropped and the database
 remains empty.
 .
 - **`"username"`** (optional, string) : an InfluxDB user name (usually
 [non-admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#non-admin-users)).
 It will be used to read/write points in the database on GET/PUT/DELETE zenoh
 operations.
 .
 - **`"password"`** (optional, string) : the user's password.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to InfluxDB concepts
 Each **storage** will map to an InfluxDB **database**.
 Each **key** to store will map to an InfluxDB
 [**measurement**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#measurement)
 named with the key stripped from the `"strip_prefix"` property (see below).
 Each **key/value** put into the storage will map to an InfluxDB
 [**point**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#point)
 reusing the timestamp set by zenoh
 (but with a precision of nanoseconds). The fileds and tags of the point is are
 the following:
  - `"kind"` tag: the zenoh change kind (`"PUT"` for a value that have been put,
 or `"DEL"` to mark the deletion of the key)
  - `"timestamp"` field: the original zenoh timestamp
  - `"encoding"` field: the value's encoding flag
  - `"base64"` field: a boolean indicating if the value is encoded in base64
  - `"value"`field: the value as a string, possibly encoded in base64 for binary
 values.
 .
 ### Behaviour on deletion
 On deletion of a key, all points with a timestamp before the deletion message
 are deleted.
 A point with `"kind"="DEL`" is inserted (to avoid re-insertion of points with
 an older timestamp in case of un-ordered messages).
 After a delay (5 seconds), the measurement corresponding to the deleted key is
 dropped if it still contains no points.
 .
 ### Behaviour on GET
 On GET operations, by default the storage returns only the latest point for
 each key/measurement.
 This is to be coherent with other backends technologies that only store 1 value
 per-key.
 If you want to get time-series as a result of a GET operation, you need to
 specify a time range via
 the `"_time"`argument in your
 [Selector](https://github.com/eclipse-zenoh/roadmap/tree/main/rfcs/ALL/Selectors).
 .
 Examples of selectors:
 ```bash
   # get the complete time-series
   /demo/example/**?_time=[..]
 .
   # get points within a fixed date interval
   /demo/example/influxdb/**?_time=[2020-01-01T00:00:00Z..2020-01-02T12:00:00.000000000Z]
 .
   # get points within a relative date interval
   /demo/example/influxdb/**?_time=[now(-2d)..now(-1d)]
 ```
 .
 See the [`"_time"`
 RFC](https://github.com/eclipse-zenoh/roadmap/blob/main/rfcs/ALL/Selectors/_time.md)
 for a complete description of the time range format
 .
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-influxdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-influxdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-influxdb
 ```
 .
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-influxdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-influxdb

Package: zenoh-backend-influxdb
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 4913
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-influxdb_0.7.2-rc_amd64.deb
Size: 1543928
MD5sum: 64d681f05f7716ed9ecce3a4cdfd4baa
SHA1: 2e26758816ed369e3e307bc3641ee44978480ad8
SHA256: 5239a263dbd70c9495fd63d4d88e7bee56a54bb8890c0a51bb5a24d59631a571
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using InfluxDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # InfluxDB backend
 .
 In Zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on an
 [InfluxDB](https://www.influxdata.com/products/influxdb/) server
 to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_influxdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 :warning: InfluxDB 2.x is not yet supported. InfluxDB 1.8 minimum is required.
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_influxdb` library file is available in `~/.zenoh/lib`.
  - You have an InfluxDB service running and listening on
 `http://localhost:8086`
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing for example:
     ```json5
     {
       plugins: {
         // configuration of "storage_manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "influxdb" volume (the
 "zenoh_backend_influxdb" backend library will be loaded at startup)
             influxdb: {
               // URL to the InfluxDB service
               url: "http://localhost:8086",
               private: {
                 // If needed: InfluxDB credentials, preferably admin for
 databases creation and drop
                 //username: "admin",
                 //password: "password"
               }
             }
           },
           storages: {
             // configuration of a "demo" storage using the "influxdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               // this option is optional
               strip_prefix: "demo/example",
               volume: {
                 id: "influxdb",
                 // the database name within InfluxDB
                 db: "zenoh_example",
                 // if the database doesn't exist, create it
                 create_db: true,
                 // strategy on storage closure
                 on_closure: "drop_db",
                 private: {
                   // If needed: InfluxDB credentials, with read/write
 privileges for the database
                   //username: "user",
                   //password: "password"
                 }
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "influxdb" volume (the "zenoh_backend_fs" library will be loaded),
 connected to InfluxDB service on http://localhost:8086:
     `curl -X PUT -H 'content-type:application/json' -d
 '{url:"http://localhost:8086"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/influxdb`
   - Add the "demo" storage using the "influxdb" volume:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",volume:{id:"influxdb",db:"zenoh_example",create_db:true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put some values at different time intervals
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-2" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-3" http://localhost:8000/demo/example/test
 .
 # Retrive them as a time serie where '_time=[..]' means "infinite time range"
 curl -g 'http://localhost:8000/demo/example/test?_time=[..]'
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test running both the zenoh router and the InfluxDB
 service in Docker containers:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_influxdb.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, replacing the URL to InfluxDB with
 `http://influxdb:8086` (instead of localhost)
 -->
 .
 -------------------------------
 ## Volume configuration
 InfluxDB-backed volumes need some configuration to work:
 .
 - **`"url"`** (**required**) : a URL to the InfluxDB service. Example:
 `http://localhost:8086`
 .
 - **`"username"`** (optional) : an [InfluxDB
 admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#admin-users)
 user name. It will be used for creation of databases, granting read/write
 privileges of databases mapped to storages and dropping of databases and
 measurements.
 .
 - **`"password"`** (optional) : the admin user's password.
 .
 Both `username` and `password` should be hidden behind a `private` gate, as
 shown in the example [above](#setup-via-a-json5-configuration-file). In
 general, if you wish for a part of the configuration to be hidden when
 configuration is queried, you should hide it behind a `private` gate.
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a `influxdb` backed volume may have additional
 configuration through the `volume` section:
 - **`"db"`** (optional, string) : the InfluxDB database name the storage will
 map into. If not specified, a random name will be generated, and the
 corresponding database will be created (even if `"create_db"` is not set).
 .
 - **`"create_db"`** (optional, boolean) : create the InfluxDB database if not
 already existing.
   By default the database is not created, unless `"db"` property is not
 specified.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 3 options:
   - *unset* or `"do_nothing"`: the database remains untouched (this is the
 default behaviour)
   - `"drop_db"`: the database is dropped (i.e. removed)
   - `"drop_series"`: all the series (measurements) are dropped and the database
 remains empty.
 .
 - **`"username"`** (optional, string) : an InfluxDB user name (usually
 [non-admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#non-admin-users)).
 It will be used to read/write points in the database on GET/PUT/DELETE zenoh
 operations.
 .
 - **`"password"`** (optional, string) : the user's password.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to InfluxDB concepts
 Each **storage** will map to an InfluxDB **database**.
 Each **key** to store will map to an InfluxDB
 [**measurement**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#measurement)
 named with the key stripped from the `"strip_prefix"` property (see below).
 Each **key/value** put into the storage will map to an InfluxDB
 [**point**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#point)
 reusing the timestamp set by zenoh
 (but with a precision of nanoseconds). The fileds and tags of the point is are
 the following:
  - `"kind"` tag: the zenoh change kind (`"PUT"` for a value that have been put,
 or `"DEL"` to mark the deletion of the key)
  - `"timestamp"` field: the original zenoh timestamp
  - `"encoding"` field: the value's encoding flag
  - `"base64"` field: a boolean indicating if the value is encoded in base64
  - `"value"`field: the value as a string, possibly encoded in base64 for binary
 values.
 .
 ### Behaviour on deletion
 On deletion of a key, all points with a timestamp before the deletion message
 are deleted.
 A point with `"kind"="DEL`" is inserted (to avoid re-insertion of points with
 an older timestamp in case of un-ordered messages).
 After a delay (5 seconds), the measurement corresponding to the deleted key is
 dropped if it still contains no points.
 .
 ### Behaviour on GET
 On GET operations, by default the storage returns only the latest point for
 each key/measurement.
 This is to be coherent with other backends technologies that only store 1 value
 per-key.
 If you want to get time-series as a result of a GET operation, you need to
 specify a time range via
 the `"_time"`argument in your
 [Selector](https://github.com/eclipse-zenoh/roadmap/tree/main/rfcs/ALL/Selectors).
 .
 Examples of selectors:
 ```bash
   # get the complete time-series
   /demo/example/**?_time=[..]
 .
   # get points within a fixed date interval
   /demo/example/influxdb/**?_time=[2020-01-01T00:00:00Z..2020-01-02T12:00:00.000000000Z]
 .
   # get points within a relative date interval
   /demo/example/influxdb/**?_time=[now(-2d)..now(-1d)]
 ```
 .
 See the [`"_time"`
 RFC](https://github.com/eclipse-zenoh/roadmap/blob/main/rfcs/ALL/Selectors/_time.md)
 for a complete description of the time range format
 .
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-influxdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-influxdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-influxdb
 ```
 .
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-influxdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-influxdb

Package: zenoh-backend-influxdb
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 4417
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-influxdb_0.7.2-rc_arm64.deb
Size: 1381488
MD5sum: 685a9d106459f5a02938befe38b0db47
SHA1: 538c21b018526465aa5be04fc550b06826e35220
SHA256: bc5170f8c194dd5eb6d20baad698aa140e230ef8f2933f2bbdab78189ba6d15e
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using InfluxDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # InfluxDB backend
 .
 In Zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on an
 [InfluxDB](https://www.influxdata.com/products/influxdb/) server
 to implement the storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_influxdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 :warning: InfluxDB 2.x is not yet supported. InfluxDB 1.8 minimum is required.
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_influxdb` library file is available in `~/.zenoh/lib`.
  - You have an InfluxDB service running and listening on
 `http://localhost:8086`
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing for example:
     ```json5
     {
       plugins: {
         // configuration of "storage_manager" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "influxdb" volume (the
 "zenoh_backend_influxdb" backend library will be loaded at startup)
             influxdb: {
               // URL to the InfluxDB service
               url: "http://localhost:8086",
               private: {
                 // If needed: InfluxDB credentials, preferably admin for
 databases creation and drop
                 //username: "admin",
                 //password: "password"
               }
             }
           },
           storages: {
             // configuration of a "demo" storage using the "influxdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               // this option is optional
               strip_prefix: "demo/example",
               volume: {
                 id: "influxdb",
                 // the database name within InfluxDB
                 db: "zenoh_example",
                 // if the database doesn't exist, create it
                 create_db: true,
                 // strategy on storage closure
                 on_closure: "drop_db",
                 private: {
                   // If needed: InfluxDB credentials, with read/write
 privileges for the database
                   //username: "user",
                   //password: "password"
                 }
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "influxdb" volume (the "zenoh_backend_fs" library will be loaded),
 connected to InfluxDB service on http://localhost:8086:
     `curl -X PUT -H 'content-type:application/json' -d
 '{url:"http://localhost:8086"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/influxdb`
   - Add the "demo" storage using the "influxdb" volume:
     `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",volume:{id:"influxdb",db:"zenoh_example",create_db:true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put some values at different time intervals
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-2" http://localhost:8000/demo/example/test
 curl -X PUT -d "TEST-3" http://localhost:8000/demo/example/test
 .
 # Retrive them as a time serie where '_time=[..]' means "infinite time range"
 curl -g 'http://localhost:8000/demo/example/test?_time=[..]'
 ```
 .
 <!-- TODO: after release of eclipse/zenoh:0.6.0 update wrt. conf file and
 uncomment this:
 .
 ### **Usage with `eclipse/zenoh` Docker image**
 Alternatively, you can test running both the zenoh router and the InfluxDB
 service in Docker containers:
  - Download the
 [docker-compose.yml](https://github.com/eclipse-zenoh/zenoh-backend-influxdb/blob/master/docker-compose.yml)
 file
  - In the same directory, create the `./zenoh_docker/lib` sub-directories and
 place the `libzenoh_backend_influxdb.so` library
    for `x86_64-unknown-linux-musl` target within.
  - Start the containers running
    ```bash
    docker-compose up -d
    ```
  - Run the `curl` commands above, replacing the URL to InfluxDB with
 `http://influxdb:8086` (instead of localhost)
 -->
 .
 -------------------------------
 ## Volume configuration
 InfluxDB-backed volumes need some configuration to work:
 .
 - **`"url"`** (**required**) : a URL to the InfluxDB service. Example:
 `http://localhost:8086`
 .
 - **`"username"`** (optional) : an [InfluxDB
 admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#admin-users)
 user name. It will be used for creation of databases, granting read/write
 privileges of databases mapped to storages and dropping of databases and
 measurements.
 .
 - **`"password"`** (optional) : the admin user's password.
 .
 Both `username` and `password` should be hidden behind a `private` gate, as
 shown in the example [above](#setup-via-a-json5-configuration-file). In
 general, if you wish for a part of the configuration to be hidden when
 configuration is queried, you should hide it behind a `private` gate.
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a `influxdb` backed volume may have additional
 configuration through the `volume` section:
 - **`"db"`** (optional, string) : the InfluxDB database name the storage will
 map into. If not specified, a random name will be generated, and the
 corresponding database will be created (even if `"create_db"` is not set).
 .
 - **`"create_db"`** (optional, boolean) : create the InfluxDB database if not
 already existing.
   By default the database is not created, unless `"db"` property is not
 specified.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 3 options:
   - *unset* or `"do_nothing"`: the database remains untouched (this is the
 default behaviour)
   - `"drop_db"`: the database is dropped (i.e. removed)
   - `"drop_series"`: all the series (measurements) are dropped and the database
 remains empty.
 .
 - **`"username"`** (optional, string) : an InfluxDB user name (usually
 [non-admin](https://docs.influxdata.com/influxdb/v1.8/administration/authentication_and_authorization/#non-admin-users)).
 It will be used to read/write points in the database on GET/PUT/DELETE zenoh
 operations.
 .
 - **`"password"`** (optional, string) : the user's password.
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to InfluxDB concepts
 Each **storage** will map to an InfluxDB **database**.
 Each **key** to store will map to an InfluxDB
 [**measurement**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#measurement)
 named with the key stripped from the `"strip_prefix"` property (see below).
 Each **key/value** put into the storage will map to an InfluxDB
 [**point**](https://docs.influxdata.com/influxdb/v1.8/concepts/key_concepts/#point)
 reusing the timestamp set by zenoh
 (but with a precision of nanoseconds). The fileds and tags of the point is are
 the following:
  - `"kind"` tag: the zenoh change kind (`"PUT"` for a value that have been put,
 or `"DEL"` to mark the deletion of the key)
  - `"timestamp"` field: the original zenoh timestamp
  - `"encoding"` field: the value's encoding flag
  - `"base64"` field: a boolean indicating if the value is encoded in base64
  - `"value"`field: the value as a string, possibly encoded in base64 for binary
 values.
 .
 ### Behaviour on deletion
 On deletion of a key, all points with a timestamp before the deletion message
 are deleted.
 A point with `"kind"="DEL`" is inserted (to avoid re-insertion of points with
 an older timestamp in case of un-ordered messages).
 After a delay (5 seconds), the measurement corresponding to the deleted key is
 dropped if it still contains no points.
 .
 ### Behaviour on GET
 On GET operations, by default the storage returns only the latest point for
 each key/measurement.
 This is to be coherent with other backends technologies that only store 1 value
 per-key.
 If you want to get time-series as a result of a GET operation, you need to
 specify a time range via
 the `"_time"`argument in your
 [Selector](https://github.com/eclipse-zenoh/roadmap/tree/main/rfcs/ALL/Selectors).
 .
 Examples of selectors:
 ```bash
   # get the complete time-series
   /demo/example/**?_time=[..]
 .
   # get points within a fixed date interval
   /demo/example/influxdb/**?_time=[2020-01-01T00:00:00Z..2020-01-02T12:00:00.000000000Z]
 .
   # get points within a relative date interval
   /demo/example/influxdb/**?_time=[now(-2d)..now(-1d)]
 ```
 .
 See the [`"_time"`
 RFC](https://github.com/eclipse-zenoh/roadmap/blob/main/rfcs/ALL/Selectors/_time.md)
 for a complete description of the time range format
 .
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-influxdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-influxdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-influxdb
 ```
 .
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-influxdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-influxdb

Package: zenoh-backend-rocksdb
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 8245
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-rocksdb_0.7.2-rc_arm64.deb
Size: 2512020
MD5sum: ce13ce19e0f94996a944df3f97a061ae
SHA1: 1388a11b4eadfd0306dd2b3d0fc601e37df2d1d0
SHA256: 6265d9986c95862a8fd7eb36fecc4caf1a0eca40e36dc56113b228b70763d668
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using RocksDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # RocksDB backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on [RocksDB](https://rocksdb.org/) to implement the
 storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_rocksdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_rocksdb` library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_ROCKSDB_ROOT` environment variable to the
 directory where you want the RocksDB databases
    to be stored. If you don't declare it, the `~/.zenoh/zenoh_backend_rocksdb`
 directory will be used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storages" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "rocksdb" volume (the "zenoh_backend_rocksdb"
 backend library will be loaded at startup)
             rocksdb: {}
           },
           storages: {
             // configuration of a "demo" storage using the "rocksdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               strip_prefix: "demo/example",
               volume: {
                 id: "rocksdb",
                 // the RocksDB database will be stored in this directory
 (relative to ${ZENOH_BACKEND_ROCKSDB_ROOT})
                 dir: "example",
                 // create the RocksDB database if not already existing
                 create_db: true
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "rocksdb" backend (the "zenoh_backend_rocksdb" library will be
 loaded):
    `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/rocksdb`
   - Add the "demo" storage using the "rocksdb" backend:
    `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example",volume: {id:
 "rocksdb",dir: "example",create_db: true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored in the RocksDB database
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a RocksDB-backed volume must specify some additional
 configuration as shown [above](#setup-via-a-json5-configuration-file):
 - **`"dir"`** (**required**, string) : The name of directory where the RocksDB
 database is stored.
   The absolute path will be `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`.
 .
 - **`"create_db"`** (optional, boolean) : create the RocksDB database if not
 already existing. Not set by default.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"read_only"`** (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't put anything
 in RocksDB database. Not set by default. *(the value doesn't matter, only the
 property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 2 options:
   - *unset*: the database remains untouched (this is the default behaviour)
   - `"destroy_db"`: the database is destroyed (i.e. removed)
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to RocksDB database
 Each **storage** will map to a RocksDB database stored in directory:
 `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_ROCKSDB_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_rocksdb`
 will be used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to 2 **key/values** in
 the database:
   * For both, the database key is the zenoh key, stripped from the
 `"strip_prefix"` property specified at storage creation.
   * In the `"default"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with the zenoh encoded value as a value.
   * In the `"data_info"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with a bytes buffer encoded in this order:
       - the Timestamp encoded as: 8 bytes for the time + 16 bytes for the HLC
 ID
       - a "is deleted" flag encoded as a boolean on 1 byte
       - the encoding prefix flag encoded as a ZInt (variable length)
       - the encoding suffix encoded as a String (string length as a ZInt +
 string bytes without ending `\0`)
 .
 ### Behaviour on deletion
 On deletion of a key, the corresponding key is removed from the `"default"`
 Column Family. An entry with the
 "deletion" flag set to true and the deletion timestamp is inserted in the
 `"data-info"` Column Family
 (to avoid re-insertion of points with an older timestamp in case of un-ordered
 messages).
 At regular interval, a task cleans-up the `"data-info"` Column Family from
 entries with old timestamps and
 the "deletion" flag set to true
 .
 ### Behaviour on GET
 On GET operations:
   * if the selector is a unique key (i.e. not containing any `'*'`): the value
 and its encoding and timestamp
     for the corresponding key are directly retrieved from the 2 Column Families
 using `get` RocksDB operation.
   * if the selector is a key expression: the storage searches for matching
 keys, leveraging RocksDB's [Prefix
 Seek](https://github.com/facebook/rocksdb/wiki/Prefix-Seek) if possible to
 minimize the number of entries to check.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-rocksdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-rocksdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-rocksdb
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb

Package: zenoh-backend-rocksdb
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 9433
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-rocksdb_0.7.2-rc_amd64.deb
Size: 2899356
MD5sum: a13ea064e09d4da8f268e585cc68fce1
SHA1: bc986459c6c29a3572ce0256d3a5c339c4906ff6
SHA256: 130845499a2cd10125dca802b6984235e15bbe19571cdbf00e062b1f70e19e01
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using RocksDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # RocksDB backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on [RocksDB](https://rocksdb.org/) to implement the
 storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_rocksdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_rocksdb` library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_ROCKSDB_ROOT` environment variable to the
 directory where you want the RocksDB databases
    to be stored. If you don't declare it, the `~/.zenoh/zenoh_backend_rocksdb`
 directory will be used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storages" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "rocksdb" volume (the "zenoh_backend_rocksdb"
 backend library will be loaded at startup)
             rocksdb: {}
           },
           storages: {
             // configuration of a "demo" storage using the "rocksdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               strip_prefix: "demo/example",
               volume: {
                 id: "rocksdb",
                 // the RocksDB database will be stored in this directory
 (relative to ${ZENOH_BACKEND_ROCKSDB_ROOT})
                 dir: "example",
                 // create the RocksDB database if not already existing
                 create_db: true
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "rocksdb" backend (the "zenoh_backend_rocksdb" library will be
 loaded):
    `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/rocksdb`
   - Add the "demo" storage using the "rocksdb" backend:
    `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example",volume: {id:
 "rocksdb",dir: "example",create_db: true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored in the RocksDB database
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a RocksDB-backed volume must specify some additional
 configuration as shown [above](#setup-via-a-json5-configuration-file):
 - **`"dir"`** (**required**, string) : The name of directory where the RocksDB
 database is stored.
   The absolute path will be `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`.
 .
 - **`"create_db"`** (optional, boolean) : create the RocksDB database if not
 already existing. Not set by default.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"read_only"`** (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't put anything
 in RocksDB database. Not set by default. *(the value doesn't matter, only the
 property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 2 options:
   - *unset*: the database remains untouched (this is the default behaviour)
   - `"destroy_db"`: the database is destroyed (i.e. removed)
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to RocksDB database
 Each **storage** will map to a RocksDB database stored in directory:
 `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_ROCKSDB_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_rocksdb`
 will be used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to 2 **key/values** in
 the database:
   * For both, the database key is the zenoh key, stripped from the
 `"strip_prefix"` property specified at storage creation.
   * In the `"default"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with the zenoh encoded value as a value.
   * In the `"data_info"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with a bytes buffer encoded in this order:
       - the Timestamp encoded as: 8 bytes for the time + 16 bytes for the HLC
 ID
       - a "is deleted" flag encoded as a boolean on 1 byte
       - the encoding prefix flag encoded as a ZInt (variable length)
       - the encoding suffix encoded as a String (string length as a ZInt +
 string bytes without ending `\0`)
 .
 ### Behaviour on deletion
 On deletion of a key, the corresponding key is removed from the `"default"`
 Column Family. An entry with the
 "deletion" flag set to true and the deletion timestamp is inserted in the
 `"data-info"` Column Family
 (to avoid re-insertion of points with an older timestamp in case of un-ordered
 messages).
 At regular interval, a task cleans-up the `"data-info"` Column Family from
 entries with old timestamps and
 the "deletion" flag set to true
 .
 ### Behaviour on GET
 On GET operations:
   * if the selector is a unique key (i.e. not containing any `'*'`): the value
 and its encoding and timestamp
     for the corresponding key are directly retrieved from the 2 Column Families
 using `get` RocksDB operation.
   * if the selector is a key expression: the storage searches for matching
 keys, leveraging RocksDB's [Prefix
 Seek](https://github.com/facebook/rocksdb/wiki/Prefix-Seek) if possible to
 minimize the number of entries to check.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-rocksdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-rocksdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-rocksdb
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb

Package: zenoh-backend-rocksdb
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 6116
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-rocksdb_0.7.2-rc_armhf.deb
Size: 2568796
MD5sum: 4ebc4bd9ee44051b4da0a300070eb6af
SHA1: e704e9409a4355f4dcde0ce1c91a278698e03e8d
SHA256: aa5cc393afea3cf6c6ce1b715497058b960fe2622186e6416b8b24982debcc3f
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using RocksDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # RocksDB backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on [RocksDB](https://rocksdb.org/) to implement the
 storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_rocksdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_rocksdb` library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_ROCKSDB_ROOT` environment variable to the
 directory where you want the RocksDB databases
    to be stored. If you don't declare it, the `~/.zenoh/zenoh_backend_rocksdb`
 directory will be used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storages" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "rocksdb" volume (the "zenoh_backend_rocksdb"
 backend library will be loaded at startup)
             rocksdb: {}
           },
           storages: {
             // configuration of a "demo" storage using the "rocksdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               strip_prefix: "demo/example",
               volume: {
                 id: "rocksdb",
                 // the RocksDB database will be stored in this directory
 (relative to ${ZENOH_BACKEND_ROCKSDB_ROOT})
                 dir: "example",
                 // create the RocksDB database if not already existing
                 create_db: true
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "rocksdb" backend (the "zenoh_backend_rocksdb" library will be
 loaded):
    `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/rocksdb`
   - Add the "demo" storage using the "rocksdb" backend:
    `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example",volume: {id:
 "rocksdb",dir: "example",create_db: true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored in the RocksDB database
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a RocksDB-backed volume must specify some additional
 configuration as shown [above](#setup-via-a-json5-configuration-file):
 - **`"dir"`** (**required**, string) : The name of directory where the RocksDB
 database is stored.
   The absolute path will be `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`.
 .
 - **`"create_db"`** (optional, boolean) : create the RocksDB database if not
 already existing. Not set by default.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"read_only"`** (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't put anything
 in RocksDB database. Not set by default. *(the value doesn't matter, only the
 property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 2 options:
   - *unset*: the database remains untouched (this is the default behaviour)
   - `"destroy_db"`: the database is destroyed (i.e. removed)
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to RocksDB database
 Each **storage** will map to a RocksDB database stored in directory:
 `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_ROCKSDB_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_rocksdb`
 will be used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to 2 **key/values** in
 the database:
   * For both, the database key is the zenoh key, stripped from the
 `"strip_prefix"` property specified at storage creation.
   * In the `"default"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with the zenoh encoded value as a value.
   * In the `"data_info"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with a bytes buffer encoded in this order:
       - the Timestamp encoded as: 8 bytes for the time + 16 bytes for the HLC
 ID
       - a "is deleted" flag encoded as a boolean on 1 byte
       - the encoding prefix flag encoded as a ZInt (variable length)
       - the encoding suffix encoded as a String (string length as a ZInt +
 string bytes without ending `\0`)
 .
 ### Behaviour on deletion
 On deletion of a key, the corresponding key is removed from the `"default"`
 Column Family. An entry with the
 "deletion" flag set to true and the deletion timestamp is inserted in the
 `"data-info"` Column Family
 (to avoid re-insertion of points with an older timestamp in case of un-ordered
 messages).
 At regular interval, a task cleans-up the `"data-info"` Column Family from
 entries with old timestamps and
 the "deletion" flag set to true
 .
 ### Behaviour on GET
 On GET operations:
   * if the selector is a unique key (i.e. not containing any `'*'`): the value
 and its encoding and timestamp
     for the corresponding key are directly retrieved from the 2 Column Families
 using `get` RocksDB operation.
   * if the selector is a key expression: the storage searches for matching
 keys, leveraging RocksDB's [Prefix
 Seek](https://github.com/facebook/rocksdb/wiki/Prefix-Seek) if possible to
 minimize the number of entries to check.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-rocksdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-rocksdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-rocksdb
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb

Package: zenoh-backend-rocksdb
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 7912
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-rocksdb_0.7.2-rc_armel.deb
Size: 2458788
MD5sum: 0744eb7f03dfd65e933110601ec823d0
SHA1: af9bf07b1a19ddf2a224c25fd0b7f050cc2c72b6
SHA256: 8deec3bb3b54090ca3cc7fb7282c6e6e69770c079e1a7af7cf46bed40071d8cf
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using RocksDB
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # RocksDB backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh documentation](http://zenoh.io/docs/manual/backends/) for more
 details.
 .
 This backend relies on [RocksDB](https://rocksdb.org/) to implement the
 storages.
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`zenoh_backend_rocksdb`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Prerequisites:
  - You have a zenoh router (`zenohd`) installed, and the
 `zenoh_backend_rocksdb` library file is available in `~/.zenoh/lib`.
  - Declare the `ZENOH_BACKEND_ROCKSDB_ROOT` environment variable to the
 directory where you want the RocksDB databases
    to be stored. If you don't declare it, the `~/.zenoh/zenoh_backend_rocksdb`
 directory will be used.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API.
 .
 ### **Setup via a JSON5 configuration file**
 .
   - Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         // configuration of "storages" plugin:
         storage_manager: {
           volumes: {
             // configuration of a "rocksdb" volume (the "zenoh_backend_rocksdb"
 backend library will be loaded at startup)
             rocksdb: {}
           },
           storages: {
             // configuration of a "demo" storage using the "rocksdb" volume
             demo: {
               // the key expression this storage will subscribes to
               key_expr: "demo/example/**",
               // this prefix will be stripped from the received key when
 converting to database key.
               // i.e.: "demo/example/a/b" will be stored as "a/b"
               strip_prefix: "demo/example",
               volume: {
                 id: "rocksdb",
                 // the RocksDB database will be stored in this directory
 (relative to ${ZENOH_BACKEND_ROCKSDB_ROOT})
                 dir: "example",
                 // create the RocksDB database if not already existing
                 create_db: true
               }
             }
           }
         },
         // Optionally, add the REST plugin
         rest: { http_port: 8000 }
       }
     }
     ```
   - Run the zenoh router with:
     `zenohd -c zenoh.json5`
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
   - Run the zenoh router, with write permissions to its admin space:
     `zenohd --adminspace-permissions rw`
   - Add the "rocksdb" backend (the "zenoh_backend_rocksdb" library will be
 loaded):
    `curl -X PUT -H 'content-type:application/json' -d '{}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/rocksdb`
   - Add the "demo" storage using the "rocksdb" backend:
    `curl -X PUT -H 'content-type:application/json' -d
 '{key_expr:"demo/example/**",strip_prefix:"demo/example",volume: {id:
 "rocksdb",dir: "example",create_db: true}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/demo`
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 ```bash
 # Put values that will be stored in the RocksDB database
 curl -X PUT -d "TEST-1" http://localhost:8000/demo/example/test-1
 curl -X PUT -d "B" http://localhost:8000/demo/example/a/b
 .
 # Retrive the values
 curl http://localhost:8000/demo/example/**
 ```
 .
 -------------------------------
 ## Volume-specific storage configuration
 Storages relying on a RocksDB-backed volume must specify some additional
 configuration as shown [above](#setup-via-a-json5-configuration-file):
 - **`"dir"`** (**required**, string) : The name of directory where the RocksDB
 database is stored.
   The absolute path will be `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`.
 .
 - **`"create_db"`** (optional, boolean) : create the RocksDB database if not
 already existing. Not set by default.
   *(the value doesn't matter, only the property existence is checked)*
 .
 - **`"read_only"`** (optional, boolean) : the storage will only answer to GET
 queries. It will not accept any PUT or DELETE message, and won't put anything
 in RocksDB database. Not set by default. *(the value doesn't matter, only the
 property existence is checked)*
 .
 - **`"on_closure"`** (optional, string) : the strategy to use when the Storage
 is removed. There are 2 options:
   - *unset*: the database remains untouched (this is the default behaviour)
   - `"destroy_db"`: the database is destroyed (i.e. removed)
 .
 -------------------------------
 ## **Behaviour of the backend**
 .
 ### Mapping to RocksDB database
 Each **storage** will map to a RocksDB database stored in directory:
 `${ZENOH_BACKEND_ROCKSDB_ROOT}/<dir>`, where:
   * `${ZENOH_BACKEND_ROCKSDB_ROOT}` is an environment variable that could be
 specified before zenoh router startup.
      If this variable is not specified `${ZENOH_HOME}/zenoh_backend_rocksdb`
 will be used
      (where the default value of `${ZENOH_HOME}` is `~/.zenoh`).
   * `<dir>` is the `"dir"` property specified at storage creation.
 Each zenoh **key/value** put into the storage will map to 2 **key/values** in
 the database:
   * For both, the database key is the zenoh key, stripped from the
 `"strip_prefix"` property specified at storage creation.
   * In the `"default"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with the zenoh encoded value as a value.
   * In the `"data_info"` [Column
 Family](https://github.com/facebook/rocksdb/wiki/Column-Families) the key is
     put with a bytes buffer encoded in this order:
       - the Timestamp encoded as: 8 bytes for the time + 16 bytes for the HLC
 ID
       - a "is deleted" flag encoded as a boolean on 1 byte
       - the encoding prefix flag encoded as a ZInt (variable length)
       - the encoding suffix encoded as a String (string length as a ZInt +
 string bytes without ending `\0`)
 .
 ### Behaviour on deletion
 On deletion of a key, the corresponding key is removed from the `"default"`
 Column Family. An entry with the
 "deletion" flag set to true and the deletion timestamp is inserted in the
 `"data-info"` Column Family
 (to avoid re-insertion of points with an older timestamp in case of un-ordered
 messages).
 At regular interval, a task cleans-up the `"data-info"` Column Family from
 entries with old timestamps and
 the "deletion" flag set to true
 .
 ### Behaviour on GET
 On GET operations:
   * if the selector is a unique key (i.e. not containing any `'*'`): the value
 and its encoding and timestamp
     for the corresponding key are directly retrieved from the 2 Column Families
 using `get` RocksDB operation.
   * if the selector is a key expression: the storage searches for matching
 keys, leveraging RocksDB's [Prefix
 Seek](https://github.com/facebook/rocksdb/wiki/Prefix-Seek) if possible to
 minimize the number of entries to check.
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-backend-rocksdb/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-rocksdb` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-rocksdb
 ```
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html) and
 [Clang](https://clang.llvm.org/).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-rocksdb

Package: zenoh-backend-s3
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 9070
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-s3_0.7.2-rc_armhf.deb
Size: 2299588
MD5sum: ea562335af1faf00490d368b230248d6
SHA1: 10b4b370fe0c99182c4fb88496563629af16891e
SHA256: 6dbe281ad25db9fac0750fc60d44bd9addbb6321ae24f18a6c5718ef9ff7d85e
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using AWS S3 API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/vSDSpqnbkm)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 # S3 backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh
 documentation](https://zenoh.io/docs/manual/plugin-storage-manager/#backends-and-volumes)
 for more details.
 .
 This backend relies on [Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls) to
 implement the storages. It is also compatible to work with
 [MinIO](https://min.io/) object storage.
 .
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`libzenoh_backend_s3`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ---
 .
 ## **Examples of usage**
 .
 Prerequisites:
 .
 - You have a zenoh router (`zenohd`) installed, and the `libzenoh_backend_s3`
 library file is available in `~/.zenoh/lib`. Alternatively we can set a symlink
 to the library, for instance by running:
 .
   ```
   ln -s ~/zenoh-backend-s3/target/release/libzenoh_backend_s3.dylib
 ~/.zenoh/lib/libzenoh_backend_s3.dylib
   ```
 .
 - You have an S3 instance running, this could be an AmazonS3 instance or a
 MinIO instance.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API
 (see https://zenoh.io/docs/manual/plugin-storage-manager/).
 .
 **Setting up a MinIO instance**
 .
 In order to run the examples of usage from the following section, it is
 convenient to launch a MinIO instance. To launch MinIO on a Docker container
 you first, install MinIO with
 .
 ```
 docker pull minio/minio
 ```
 .
 And then you can use the following command to launch the instance:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'  -v
 ${HOME}/minio/data:/data   quay.io/minio/minio server data --console-address
 ':9090'
 ```
 .
 If successful, then the console can be accessed on http://localhost:9090.
 .
 ### **Setup via a JSON5 configuration file**
 .
 - Create a `zenoh.json5` configuration file containing:
 .
   ```json5
   {
     plugins: {
       // Configuration of "storage_manager" plugin:
       storage_manager: {
         volumes: {
           s3: {
             // AWS region to which connect (see
 https://docs.aws.amazon.com/general/latest/gr/s3.html).
             // This field is mandatory if you are going to communicate with an
 AWS S3 server and
             // optional in case you are working with a MinIO S3 server.
             region: "eu-west-1",
 .
             // Endpoint where the S3 server is located.
             // This parameter allows you to specify a custom endpoint when
 working with a MinIO S3
             // server.
             // This field is mandatory if you are working with a MinIO server
 and optional in case
             // you are working with an AWS S3 server as long as you specified
 the region, in which
             // case the endpoint will be resolved automatically.
             url: "https://s3.eu-west-1.amazonaws.com",
 .
             // Optional TLS specific parameters to enable HTTPS with MinIO.
 Configuration shared by
             // all the associated storages.
             tls: {
               // Certificate authority to authenticate the server.
               root_ca_certificate: "/home/user/certificates/minio/ca.pem",
             },
           },
         },
         storages: {
           // Configuration of a "demo" storage using the S3 volume. Each
 storage is associated to a
           // single S3 bucket.
           s3_storage: {
             // The key expression this storage will subscribes to
             key_expr: "s3/example/*",
 .
             // this prefix will be stripped from the received key when
 converting to database key.
             // i.e.: "demo/example/a/b" will be stored as "a/b"
             strip_prefix: "s3/example",
 .
             volume: {
               // Id of the volume this storage is associated to
               id: "s3",
 .
               // Bucket to which this storage is associated to
               bucket: "zenoh-bucket",
 .
               // The storage attempts to create the bucket, but if the bucket
 already exists and is
               // owned by you, then with 'reuse_bucket' you can associate that
 preexisting bucket to
               // the storage, otherwise it will fail.
               reuse_bucket: true,
 .
               // If the storage is read only, it will only handle GET requests
               read_only: false,
 .
               // strategy on storage closure, either `destroy_bucket` or
 `do_nothing`
               on_closure: "destroy_bucket",
 .
               private: {
                 // Credentials for interacting with the S3 bucket
                 access_key: "SARASAFODNN7EXAMPLE",
                 secret_key: "asADasWdKALsI/ASDP22NG/pWokSSLqEXAMPLEKEY",
               },
             },
           },
         },
       },
       // Optionally, add the REST plugin
       rest: { http_port: 8000 },
     },
   }
   ```
 .
 - Run the zenoh router with:
   ```
   zenohd -c zenoh.json5
   ```
 .
 **Volume configuration when working with AWS S3 storage**
 .
 When working with the AWS S3 storage, the region must be specified following
 the region names indicated in the [Amazon Simple Storage Service endpoints and
 quotas
 ](https://docs.aws.amazon.com/general/latest/gr/s3.html) documentation. The url
 of the endpoint is not required as the internal endpoint resolver will
 automatically
 find which one is the endpoint associated to the region specified.
 .
 All the storages associated to the volume will use the same region.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         // AWS region to which connect
         region: "eu-west-1",
     }
   },
   ...
 }
 ```
 .
 **Volume configuration when working with MinIO**
 .
 Inversely, when working with a MinIO S3 storage, then we need to specify the
 endpoint of the storage rather than the region, which will be ignored by the
 MinIO server. We can save ourselves to specify the region in that case.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         url: "http://localhost:9000",
     }
   },
   ...
 }
 ```
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
 - Run the zenoh router:
   ```
   cargo run --bin=zenohd
   ```
 - Add the "s3" backend (the "zenoh_backend_s3" library will be loaded):
   ```
   curl -X PUT -H 'content-type:application/json' -d '{url:
 "http://localhost:9000", private: {access_key: "AKIAIOSFODNN7EXAMPLE",
 secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/s3
   ```
 - Add the "s3_storage" storage using the "s3" backend:
   ```
   curl -X PUT -H 'content-type:application/json' -d '{key_expr:"s3/example/*",
 strip_prefix:"s3/example", volume: {id: "s3", bucket: "zenoh-bucket",
 create_bucket: true, region: "eu-west-3", on_closure: "do_nothing", private:
 {access_key: "AKIAIOSFODNN7EXAMPLE", secret_key:
 "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage
   ```
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 .
 ```bash
 # Put values that will be stored in the S3 storage
 curl -X PUT -H 'content-type:application/json' -d '{"example_key":
 "example_value"}' http://0.0.0.0:8000/s3/example/test
 .
 # To get the stored object
 curl -X GET -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the previous object
 curl -X DELETE -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the whole storage and the bucket if configured (note in order for
 this test to work, you need to setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage'
 .
 # To delete the whole volume (note in order for this test to work, you need to
 setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/volumes/s3'
 ```
 .
 ## **Enabling TLS on MinIO**
 .
 In order to establish secure communication through HTTPS we need to provide a
 certificate of the certificate authority that validates the server credentials.
 .
 TLS certificates can be generated as explained in the [zenoh documentation
 using Minica](https://zenoh.io/docs/manual/tls/). When running
 .
 ```
 minica --domains localhost
 ```
 .
 a private key, a public certificate and a certificate authority certificate is
 generated:
 .
 ```
 └── certificates
     ├── localhost
     │   ├── cert.pem
     │   └── key.pem
     ├── minica-key.pem
     └── minica.pem
 ```
 .
 On the config file, we need to specify the `root_ca_certificate` as this will
 allow the s3 plugin to validate the MinIO server keys.
 Example:
 .
 ```
 tls: {
   root_ca_certificate: "/home/user/certificates/minio/minica.pem",
 },
 ```
 .
 Here, the `root_ca_certificate` corresponds to the generated _minica.pem_ file.
 .
 The _cert.pem_ and _key.pem_ files correspond to the public certificate and
 private key respectively. We need to rename them as _public.crt_ and
 _private.key_ respectively and store them under the MinIO configuration
 directory (as specified in the [MinIO
 documentation](https://min.io/docs/minio/linux/operations/network-encryption.html#enabling-tls)).
 In case you are using running a docker container as previously shown, then we
 will need to mount the folder containing the certificates as a volume;
 supposing we stored our certificates under `${HOME}/minio/certs`, we need to
 start our container as follows:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' -v
 ${HOME}/minio/data:/data -v ${HOME}/minio/certs:/certs quay.io/minio/minio
 server data --certs-dir certs --console-address ':9090'
 ```
 .
 Finally the volume configuration should then look like:
 .
 ```
 storage_manager: {
   volumes: {
     s3: {
         // Endpoint where the S3 server is located
         url: "https://localhost:9000",
 .
         // Configure TLS specific parameters
         tls: {
           root_ca_certificate:
 "/home/user/certificates/minio_certs/minica.pem",
         },
     }
   },
 ```
 .
 _Note: do not forget to modify the endpoint protocol, for instance from
 `http://localhost:9090` to `https://localhost:9090`_
 .
 ---
 .
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
 .
 - https://download.eclipse.org/zenoh/zenoh-backend-s3/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-s3` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-s3
 ```
 .
 ---
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 > built with the exact same Rust version than `zenohd`. Otherwise,
 incompatibilities in memory mapping
 > of shared types between `zenohd` and the library can lead to a `"SIGSEV"`
 crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 .
 ```bash
 $ zenohd --version
 zenohd v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0 (84c898d65
 2023-04-16)
 The zenoh router v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0
 (84c898d65 2023-04-16)
 ```
 .
 Here, `zenohd` has been built with the rustc version `1.69.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.69.0
 ```
 .
 And then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-s3
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-s3

Package: zenoh-backend-s3
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 10297
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-s3_0.7.2-rc_arm64.deb
Size: 2630816
MD5sum: eaa73f62d44ce38911fad7c6aac478d6
SHA1: ab7759d926e06c9c462328c0408da769c7410006
SHA256: 46b6f934041b42b2837a8f9dd74a78808c3c99cfc36a6caf1f3ca9a52f9bfd4f
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using AWS S3 API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/vSDSpqnbkm)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 # S3 backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh
 documentation](https://zenoh.io/docs/manual/plugin-storage-manager/#backends-and-volumes)
 for more details.
 .
 This backend relies on [Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls) to
 implement the storages. It is also compatible to work with
 [MinIO](https://min.io/) object storage.
 .
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`libzenoh_backend_s3`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ---
 .
 ## **Examples of usage**
 .
 Prerequisites:
 .
 - You have a zenoh router (`zenohd`) installed, and the `libzenoh_backend_s3`
 library file is available in `~/.zenoh/lib`. Alternatively we can set a symlink
 to the library, for instance by running:
 .
   ```
   ln -s ~/zenoh-backend-s3/target/release/libzenoh_backend_s3.dylib
 ~/.zenoh/lib/libzenoh_backend_s3.dylib
   ```
 .
 - You have an S3 instance running, this could be an AmazonS3 instance or a
 MinIO instance.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API
 (see https://zenoh.io/docs/manual/plugin-storage-manager/).
 .
 **Setting up a MinIO instance**
 .
 In order to run the examples of usage from the following section, it is
 convenient to launch a MinIO instance. To launch MinIO on a Docker container
 you first, install MinIO with
 .
 ```
 docker pull minio/minio
 ```
 .
 And then you can use the following command to launch the instance:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'  -v
 ${HOME}/minio/data:/data   quay.io/minio/minio server data --console-address
 ':9090'
 ```
 .
 If successful, then the console can be accessed on http://localhost:9090.
 .
 ### **Setup via a JSON5 configuration file**
 .
 - Create a `zenoh.json5` configuration file containing:
 .
   ```json5
   {
     plugins: {
       // Configuration of "storage_manager" plugin:
       storage_manager: {
         volumes: {
           s3: {
             // AWS region to which connect (see
 https://docs.aws.amazon.com/general/latest/gr/s3.html).
             // This field is mandatory if you are going to communicate with an
 AWS S3 server and
             // optional in case you are working with a MinIO S3 server.
             region: "eu-west-1",
 .
             // Endpoint where the S3 server is located.
             // This parameter allows you to specify a custom endpoint when
 working with a MinIO S3
             // server.
             // This field is mandatory if you are working with a MinIO server
 and optional in case
             // you are working with an AWS S3 server as long as you specified
 the region, in which
             // case the endpoint will be resolved automatically.
             url: "https://s3.eu-west-1.amazonaws.com",
 .
             // Optional TLS specific parameters to enable HTTPS with MinIO.
 Configuration shared by
             // all the associated storages.
             tls: {
               // Certificate authority to authenticate the server.
               root_ca_certificate: "/home/user/certificates/minio/ca.pem",
             },
           },
         },
         storages: {
           // Configuration of a "demo" storage using the S3 volume. Each
 storage is associated to a
           // single S3 bucket.
           s3_storage: {
             // The key expression this storage will subscribes to
             key_expr: "s3/example/*",
 .
             // this prefix will be stripped from the received key when
 converting to database key.
             // i.e.: "demo/example/a/b" will be stored as "a/b"
             strip_prefix: "s3/example",
 .
             volume: {
               // Id of the volume this storage is associated to
               id: "s3",
 .
               // Bucket to which this storage is associated to
               bucket: "zenoh-bucket",
 .
               // The storage attempts to create the bucket, but if the bucket
 already exists and is
               // owned by you, then with 'reuse_bucket' you can associate that
 preexisting bucket to
               // the storage, otherwise it will fail.
               reuse_bucket: true,
 .
               // If the storage is read only, it will only handle GET requests
               read_only: false,
 .
               // strategy on storage closure, either `destroy_bucket` or
 `do_nothing`
               on_closure: "destroy_bucket",
 .
               private: {
                 // Credentials for interacting with the S3 bucket
                 access_key: "SARASAFODNN7EXAMPLE",
                 secret_key: "asADasWdKALsI/ASDP22NG/pWokSSLqEXAMPLEKEY",
               },
             },
           },
         },
       },
       // Optionally, add the REST plugin
       rest: { http_port: 8000 },
     },
   }
   ```
 .
 - Run the zenoh router with:
   ```
   zenohd -c zenoh.json5
   ```
 .
 **Volume configuration when working with AWS S3 storage**
 .
 When working with the AWS S3 storage, the region must be specified following
 the region names indicated in the [Amazon Simple Storage Service endpoints and
 quotas
 ](https://docs.aws.amazon.com/general/latest/gr/s3.html) documentation. The url
 of the endpoint is not required as the internal endpoint resolver will
 automatically
 find which one is the endpoint associated to the region specified.
 .
 All the storages associated to the volume will use the same region.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         // AWS region to which connect
         region: "eu-west-1",
     }
   },
   ...
 }
 ```
 .
 **Volume configuration when working with MinIO**
 .
 Inversely, when working with a MinIO S3 storage, then we need to specify the
 endpoint of the storage rather than the region, which will be ignored by the
 MinIO server. We can save ourselves to specify the region in that case.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         url: "http://localhost:9000",
     }
   },
   ...
 }
 ```
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
 - Run the zenoh router:
   ```
   cargo run --bin=zenohd
   ```
 - Add the "s3" backend (the "zenoh_backend_s3" library will be loaded):
   ```
   curl -X PUT -H 'content-type:application/json' -d '{url:
 "http://localhost:9000", private: {access_key: "AKIAIOSFODNN7EXAMPLE",
 secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/s3
   ```
 - Add the "s3_storage" storage using the "s3" backend:
   ```
   curl -X PUT -H 'content-type:application/json' -d '{key_expr:"s3/example/*",
 strip_prefix:"s3/example", volume: {id: "s3", bucket: "zenoh-bucket",
 create_bucket: true, region: "eu-west-3", on_closure: "do_nothing", private:
 {access_key: "AKIAIOSFODNN7EXAMPLE", secret_key:
 "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage
   ```
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 .
 ```bash
 # Put values that will be stored in the S3 storage
 curl -X PUT -H 'content-type:application/json' -d '{"example_key":
 "example_value"}' http://0.0.0.0:8000/s3/example/test
 .
 # To get the stored object
 curl -X GET -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the previous object
 curl -X DELETE -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the whole storage and the bucket if configured (note in order for
 this test to work, you need to setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage'
 .
 # To delete the whole volume (note in order for this test to work, you need to
 setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/volumes/s3'
 ```
 .
 ## **Enabling TLS on MinIO**
 .
 In order to establish secure communication through HTTPS we need to provide a
 certificate of the certificate authority that validates the server credentials.
 .
 TLS certificates can be generated as explained in the [zenoh documentation
 using Minica](https://zenoh.io/docs/manual/tls/). When running
 .
 ```
 minica --domains localhost
 ```
 .
 a private key, a public certificate and a certificate authority certificate is
 generated:
 .
 ```
 └── certificates
     ├── localhost
     │   ├── cert.pem
     │   └── key.pem
     ├── minica-key.pem
     └── minica.pem
 ```
 .
 On the config file, we need to specify the `root_ca_certificate` as this will
 allow the s3 plugin to validate the MinIO server keys.
 Example:
 .
 ```
 tls: {
   root_ca_certificate: "/home/user/certificates/minio/minica.pem",
 },
 ```
 .
 Here, the `root_ca_certificate` corresponds to the generated _minica.pem_ file.
 .
 The _cert.pem_ and _key.pem_ files correspond to the public certificate and
 private key respectively. We need to rename them as _public.crt_ and
 _private.key_ respectively and store them under the MinIO configuration
 directory (as specified in the [MinIO
 documentation](https://min.io/docs/minio/linux/operations/network-encryption.html#enabling-tls)).
 In case you are using running a docker container as previously shown, then we
 will need to mount the folder containing the certificates as a volume;
 supposing we stored our certificates under `${HOME}/minio/certs`, we need to
 start our container as follows:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' -v
 ${HOME}/minio/data:/data -v ${HOME}/minio/certs:/certs quay.io/minio/minio
 server data --certs-dir certs --console-address ':9090'
 ```
 .
 Finally the volume configuration should then look like:
 .
 ```
 storage_manager: {
   volumes: {
     s3: {
         // Endpoint where the S3 server is located
         url: "https://localhost:9000",
 .
         // Configure TLS specific parameters
         tls: {
           root_ca_certificate:
 "/home/user/certificates/minio_certs/minica.pem",
         },
     }
   },
 ```
 .
 _Note: do not forget to modify the endpoint protocol, for instance from
 `http://localhost:9090` to `https://localhost:9090`_
 .
 ---
 .
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
 .
 - https://download.eclipse.org/zenoh/zenoh-backend-s3/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-s3` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-s3
 ```
 .
 ---
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 > built with the exact same Rust version than `zenohd`. Otherwise,
 incompatibilities in memory mapping
 > of shared types between `zenohd` and the library can lead to a `"SIGSEV"`
 crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 .
 ```bash
 $ zenohd --version
 zenohd v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0 (84c898d65
 2023-04-16)
 The zenoh router v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0
 (84c898d65 2023-04-16)
 ```
 .
 Here, `zenohd` has been built with the rustc version `1.69.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.69.0
 ```
 .
 And then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-s3
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-s3

Package: zenoh-backend-s3
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 11521
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-s3_0.7.2-rc_amd64.deb
Size: 2894992
MD5sum: 9964a688f9778da9b54f31df48cb11ef
SHA1: d97a8e2b35a3690df55f90971717cc291774f82e
SHA256: a5dc06ee8847adae2c0e1f01b212b269d8d241a7c4e4f1ae809c55871d3f67e6
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using AWS S3 API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/vSDSpqnbkm)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 # S3 backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh
 documentation](https://zenoh.io/docs/manual/plugin-storage-manager/#backends-and-volumes)
 for more details.
 .
 This backend relies on [Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls) to
 implement the storages. It is also compatible to work with
 [MinIO](https://min.io/) object storage.
 .
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`libzenoh_backend_s3`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ---
 .
 ## **Examples of usage**
 .
 Prerequisites:
 .
 - You have a zenoh router (`zenohd`) installed, and the `libzenoh_backend_s3`
 library file is available in `~/.zenoh/lib`. Alternatively we can set a symlink
 to the library, for instance by running:
 .
   ```
   ln -s ~/zenoh-backend-s3/target/release/libzenoh_backend_s3.dylib
 ~/.zenoh/lib/libzenoh_backend_s3.dylib
   ```
 .
 - You have an S3 instance running, this could be an AmazonS3 instance or a
 MinIO instance.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API
 (see https://zenoh.io/docs/manual/plugin-storage-manager/).
 .
 **Setting up a MinIO instance**
 .
 In order to run the examples of usage from the following section, it is
 convenient to launch a MinIO instance. To launch MinIO on a Docker container
 you first, install MinIO with
 .
 ```
 docker pull minio/minio
 ```
 .
 And then you can use the following command to launch the instance:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'  -v
 ${HOME}/minio/data:/data   quay.io/minio/minio server data --console-address
 ':9090'
 ```
 .
 If successful, then the console can be accessed on http://localhost:9090.
 .
 ### **Setup via a JSON5 configuration file**
 .
 - Create a `zenoh.json5` configuration file containing:
 .
   ```json5
   {
     plugins: {
       // Configuration of "storage_manager" plugin:
       storage_manager: {
         volumes: {
           s3: {
             // AWS region to which connect (see
 https://docs.aws.amazon.com/general/latest/gr/s3.html).
             // This field is mandatory if you are going to communicate with an
 AWS S3 server and
             // optional in case you are working with a MinIO S3 server.
             region: "eu-west-1",
 .
             // Endpoint where the S3 server is located.
             // This parameter allows you to specify a custom endpoint when
 working with a MinIO S3
             // server.
             // This field is mandatory if you are working with a MinIO server
 and optional in case
             // you are working with an AWS S3 server as long as you specified
 the region, in which
             // case the endpoint will be resolved automatically.
             url: "https://s3.eu-west-1.amazonaws.com",
 .
             // Optional TLS specific parameters to enable HTTPS with MinIO.
 Configuration shared by
             // all the associated storages.
             tls: {
               // Certificate authority to authenticate the server.
               root_ca_certificate: "/home/user/certificates/minio/ca.pem",
             },
           },
         },
         storages: {
           // Configuration of a "demo" storage using the S3 volume. Each
 storage is associated to a
           // single S3 bucket.
           s3_storage: {
             // The key expression this storage will subscribes to
             key_expr: "s3/example/*",
 .
             // this prefix will be stripped from the received key when
 converting to database key.
             // i.e.: "demo/example/a/b" will be stored as "a/b"
             strip_prefix: "s3/example",
 .
             volume: {
               // Id of the volume this storage is associated to
               id: "s3",
 .
               // Bucket to which this storage is associated to
               bucket: "zenoh-bucket",
 .
               // The storage attempts to create the bucket, but if the bucket
 already exists and is
               // owned by you, then with 'reuse_bucket' you can associate that
 preexisting bucket to
               // the storage, otherwise it will fail.
               reuse_bucket: true,
 .
               // If the storage is read only, it will only handle GET requests
               read_only: false,
 .
               // strategy on storage closure, either `destroy_bucket` or
 `do_nothing`
               on_closure: "destroy_bucket",
 .
               private: {
                 // Credentials for interacting with the S3 bucket
                 access_key: "SARASAFODNN7EXAMPLE",
                 secret_key: "asADasWdKALsI/ASDP22NG/pWokSSLqEXAMPLEKEY",
               },
             },
           },
         },
       },
       // Optionally, add the REST plugin
       rest: { http_port: 8000 },
     },
   }
   ```
 .
 - Run the zenoh router with:
   ```
   zenohd -c zenoh.json5
   ```
 .
 **Volume configuration when working with AWS S3 storage**
 .
 When working with the AWS S3 storage, the region must be specified following
 the region names indicated in the [Amazon Simple Storage Service endpoints and
 quotas
 ](https://docs.aws.amazon.com/general/latest/gr/s3.html) documentation. The url
 of the endpoint is not required as the internal endpoint resolver will
 automatically
 find which one is the endpoint associated to the region specified.
 .
 All the storages associated to the volume will use the same region.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         // AWS region to which connect
         region: "eu-west-1",
     }
   },
   ...
 }
 ```
 .
 **Volume configuration when working with MinIO**
 .
 Inversely, when working with a MinIO S3 storage, then we need to specify the
 endpoint of the storage rather than the region, which will be ignored by the
 MinIO server. We can save ourselves to specify the region in that case.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         url: "http://localhost:9000",
     }
   },
   ...
 }
 ```
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
 - Run the zenoh router:
   ```
   cargo run --bin=zenohd
   ```
 - Add the "s3" backend (the "zenoh_backend_s3" library will be loaded):
   ```
   curl -X PUT -H 'content-type:application/json' -d '{url:
 "http://localhost:9000", private: {access_key: "AKIAIOSFODNN7EXAMPLE",
 secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/s3
   ```
 - Add the "s3_storage" storage using the "s3" backend:
   ```
   curl -X PUT -H 'content-type:application/json' -d '{key_expr:"s3/example/*",
 strip_prefix:"s3/example", volume: {id: "s3", bucket: "zenoh-bucket",
 create_bucket: true, region: "eu-west-3", on_closure: "do_nothing", private:
 {access_key: "AKIAIOSFODNN7EXAMPLE", secret_key:
 "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage
   ```
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 .
 ```bash
 # Put values that will be stored in the S3 storage
 curl -X PUT -H 'content-type:application/json' -d '{"example_key":
 "example_value"}' http://0.0.0.0:8000/s3/example/test
 .
 # To get the stored object
 curl -X GET -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the previous object
 curl -X DELETE -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the whole storage and the bucket if configured (note in order for
 this test to work, you need to setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage'
 .
 # To delete the whole volume (note in order for this test to work, you need to
 setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/volumes/s3'
 ```
 .
 ## **Enabling TLS on MinIO**
 .
 In order to establish secure communication through HTTPS we need to provide a
 certificate of the certificate authority that validates the server credentials.
 .
 TLS certificates can be generated as explained in the [zenoh documentation
 using Minica](https://zenoh.io/docs/manual/tls/). When running
 .
 ```
 minica --domains localhost
 ```
 .
 a private key, a public certificate and a certificate authority certificate is
 generated:
 .
 ```
 └── certificates
     ├── localhost
     │   ├── cert.pem
     │   └── key.pem
     ├── minica-key.pem
     └── minica.pem
 ```
 .
 On the config file, we need to specify the `root_ca_certificate` as this will
 allow the s3 plugin to validate the MinIO server keys.
 Example:
 .
 ```
 tls: {
   root_ca_certificate: "/home/user/certificates/minio/minica.pem",
 },
 ```
 .
 Here, the `root_ca_certificate` corresponds to the generated _minica.pem_ file.
 .
 The _cert.pem_ and _key.pem_ files correspond to the public certificate and
 private key respectively. We need to rename them as _public.crt_ and
 _private.key_ respectively and store them under the MinIO configuration
 directory (as specified in the [MinIO
 documentation](https://min.io/docs/minio/linux/operations/network-encryption.html#enabling-tls)).
 In case you are using running a docker container as previously shown, then we
 will need to mount the folder containing the certificates as a volume;
 supposing we stored our certificates under `${HOME}/minio/certs`, we need to
 start our container as follows:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' -v
 ${HOME}/minio/data:/data -v ${HOME}/minio/certs:/certs quay.io/minio/minio
 server data --certs-dir certs --console-address ':9090'
 ```
 .
 Finally the volume configuration should then look like:
 .
 ```
 storage_manager: {
   volumes: {
     s3: {
         // Endpoint where the S3 server is located
         url: "https://localhost:9000",
 .
         // Configure TLS specific parameters
         tls: {
           root_ca_certificate:
 "/home/user/certificates/minio_certs/minica.pem",
         },
     }
   },
 ```
 .
 _Note: do not forget to modify the endpoint protocol, for instance from
 `http://localhost:9090` to `https://localhost:9090`_
 .
 ---
 .
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
 .
 - https://download.eclipse.org/zenoh/zenoh-backend-s3/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-s3` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-s3
 ```
 .
 ---
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 > built with the exact same Rust version than `zenohd`. Otherwise,
 incompatibilities in memory mapping
 > of shared types between `zenohd` and the library can lead to a `"SIGSEV"`
 crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 .
 ```bash
 $ zenohd --version
 zenohd v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0 (84c898d65
 2023-04-16)
 The zenoh router v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0
 (84c898d65 2023-04-16)
 ```
 .
 Here, `zenohd` has been built with the rustc version `1.69.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.69.0
 ```
 .
 And then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-s3
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-s3

Package: zenoh-backend-s3
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 9234
Depends: zenoh-plugin-storage-manager (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-backend-s3_0.7.2-rc_armel.deb
Size: 2295824
MD5sum: a6757c8220910b4f64a3dae755cc8f03
SHA1: 52af4faa9117f105e60a2a33682fee97c337c9d2
SHA256: 0842623f30c3280dc07a27085f11e704c462d9362ae61f63f693d8694f75ac3d
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Backend for Zenoh using AWS S3 API
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/vSDSpqnbkm)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 .
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 # S3 backend
 .
 In zenoh a backend is a storage technology (such as DBMS, time-series database,
 file system...) alowing to store the
 keys/values publications made via zenoh and return them on queries.
 See the [zenoh
 documentation](https://zenoh.io/docs/manual/plugin-storage-manager/#backends-and-volumes)
 for more details.
 .
 This backend relies on [Amazon S3](https://aws.amazon.com/s3/?nc1=h_ls) to
 implement the storages. It is also compatible to work with
 [MinIO](https://min.io/) object storage.
 .
 Its library name (without OS specific prefix and extension) that zenoh will
 rely on to find it and load it is **`libzenoh_backend_s3`**.
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ---
 .
 ## **Examples of usage**
 .
 Prerequisites:
 .
 - You have a zenoh router (`zenohd`) installed, and the `libzenoh_backend_s3`
 library file is available in `~/.zenoh/lib`. Alternatively we can set a symlink
 to the library, for instance by running:
 .
   ```
   ln -s ~/zenoh-backend-s3/target/release/libzenoh_backend_s3.dylib
 ~/.zenoh/lib/libzenoh_backend_s3.dylib
   ```
 .
 - You have an S3 instance running, this could be an AmazonS3 instance or a
 MinIO instance.
 .
 You can setup storages either at zenoh router startup via a configuration file,
 either at runtime via the zenoh admin space, using for instance the REST API
 (see https://zenoh.io/docs/manual/plugin-storage-manager/).
 .
 **Setting up a MinIO instance**
 .
 In order to run the examples of usage from the following section, it is
 convenient to launch a MinIO instance. To launch MinIO on a Docker container
 you first, install MinIO with
 .
 ```
 docker pull minio/minio
 ```
 .
 And then you can use the following command to launch the instance:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY'  -v
 ${HOME}/minio/data:/data   quay.io/minio/minio server data --console-address
 ':9090'
 ```
 .
 If successful, then the console can be accessed on http://localhost:9090.
 .
 ### **Setup via a JSON5 configuration file**
 .
 - Create a `zenoh.json5` configuration file containing:
 .
   ```json5
   {
     plugins: {
       // Configuration of "storage_manager" plugin:
       storage_manager: {
         volumes: {
           s3: {
             // AWS region to which connect (see
 https://docs.aws.amazon.com/general/latest/gr/s3.html).
             // This field is mandatory if you are going to communicate with an
 AWS S3 server and
             // optional in case you are working with a MinIO S3 server.
             region: "eu-west-1",
 .
             // Endpoint where the S3 server is located.
             // This parameter allows you to specify a custom endpoint when
 working with a MinIO S3
             // server.
             // This field is mandatory if you are working with a MinIO server
 and optional in case
             // you are working with an AWS S3 server as long as you specified
 the region, in which
             // case the endpoint will be resolved automatically.
             url: "https://s3.eu-west-1.amazonaws.com",
 .
             // Optional TLS specific parameters to enable HTTPS with MinIO.
 Configuration shared by
             // all the associated storages.
             tls: {
               // Certificate authority to authenticate the server.
               root_ca_certificate: "/home/user/certificates/minio/ca.pem",
             },
           },
         },
         storages: {
           // Configuration of a "demo" storage using the S3 volume. Each
 storage is associated to a
           // single S3 bucket.
           s3_storage: {
             // The key expression this storage will subscribes to
             key_expr: "s3/example/*",
 .
             // this prefix will be stripped from the received key when
 converting to database key.
             // i.e.: "demo/example/a/b" will be stored as "a/b"
             strip_prefix: "s3/example",
 .
             volume: {
               // Id of the volume this storage is associated to
               id: "s3",
 .
               // Bucket to which this storage is associated to
               bucket: "zenoh-bucket",
 .
               // The storage attempts to create the bucket, but if the bucket
 already exists and is
               // owned by you, then with 'reuse_bucket' you can associate that
 preexisting bucket to
               // the storage, otherwise it will fail.
               reuse_bucket: true,
 .
               // If the storage is read only, it will only handle GET requests
               read_only: false,
 .
               // strategy on storage closure, either `destroy_bucket` or
 `do_nothing`
               on_closure: "destroy_bucket",
 .
               private: {
                 // Credentials for interacting with the S3 bucket
                 access_key: "SARASAFODNN7EXAMPLE",
                 secret_key: "asADasWdKALsI/ASDP22NG/pWokSSLqEXAMPLEKEY",
               },
             },
           },
         },
       },
       // Optionally, add the REST plugin
       rest: { http_port: 8000 },
     },
   }
   ```
 .
 - Run the zenoh router with:
   ```
   zenohd -c zenoh.json5
   ```
 .
 **Volume configuration when working with AWS S3 storage**
 .
 When working with the AWS S3 storage, the region must be specified following
 the region names indicated in the [Amazon Simple Storage Service endpoints and
 quotas
 ](https://docs.aws.amazon.com/general/latest/gr/s3.html) documentation. The url
 of the endpoint is not required as the internal endpoint resolver will
 automatically
 find which one is the endpoint associated to the region specified.
 .
 All the storages associated to the volume will use the same region.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         // AWS region to which connect
         region: "eu-west-1",
     }
   },
   ...
 }
 ```
 .
 **Volume configuration when working with MinIO**
 .
 Inversely, when working with a MinIO S3 storage, then we need to specify the
 endpoint of the storage rather than the region, which will be ignored by the
 MinIO server. We can save ourselves to specify the region in that case.
 .
 The volumes section on the config file will look like:
 .
 ```
 storage_manager {
   volumes: {
     s3: {
         url: "http://localhost:9000",
     }
   },
   ...
 }
 ```
 .
 ### **Setup at runtime via `curl` commands on the admin space**
 .
 - Run the zenoh router:
   ```
   cargo run --bin=zenohd
   ```
 - Add the "s3" backend (the "zenoh_backend_s3" library will be loaded):
   ```
   curl -X PUT -H 'content-type:application/json' -d '{url:
 "http://localhost:9000", private: {access_key: "AKIAIOSFODNN7EXAMPLE",
 secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/volumes/s3
   ```
 - Add the "s3_storage" storage using the "s3" backend:
   ```
   curl -X PUT -H 'content-type:application/json' -d '{key_expr:"s3/example/*",
 strip_prefix:"s3/example", volume: {id: "s3", bucket: "zenoh-bucket",
 create_bucket: true, region: "eu-west-3", on_closure: "do_nothing", private:
 {access_key: "AKIAIOSFODNN7EXAMPLE", secret_key:
 "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}}}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage
   ```
 .
 ### **Tests using the REST API**
 .
 Using `curl` to publish and query keys/values, you can:
 .
 ```bash
 # Put values that will be stored in the S3 storage
 curl -X PUT -H 'content-type:application/json' -d '{"example_key":
 "example_value"}' http://0.0.0.0:8000/s3/example/test
 .
 # To get the stored object
 curl -X GET -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the previous object
 curl -X DELETE -H {} -d '{}' http://0.0.0.0:8000/s3/example/test
 .
 # To delete the whole storage and the bucket if configured (note in order for
 this test to work, you need to setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/storages/s3_storage'
 .
 # To delete the whole volume (note in order for this test to work, you need to
 setup adminspace read/write permissions)
 curl -X DELETE
 'http://0.0.0.0:8000/@/router/local/config/plugins/storage_manager/volumes/s3'
 ```
 .
 ## **Enabling TLS on MinIO**
 .
 In order to establish secure communication through HTTPS we need to provide a
 certificate of the certificate authority that validates the server credentials.
 .
 TLS certificates can be generated as explained in the [zenoh documentation
 using Minica](https://zenoh.io/docs/manual/tls/). When running
 .
 ```
 minica --domains localhost
 ```
 .
 a private key, a public certificate and a certificate authority certificate is
 generated:
 .
 ```
 └── certificates
     ├── localhost
     │   ├── cert.pem
     │   └── key.pem
     ├── minica-key.pem
     └── minica.pem
 ```
 .
 On the config file, we need to specify the `root_ca_certificate` as this will
 allow the s3 plugin to validate the MinIO server keys.
 Example:
 .
 ```
 tls: {
   root_ca_certificate: "/home/user/certificates/minio/minica.pem",
 },
 ```
 .
 Here, the `root_ca_certificate` corresponds to the generated _minica.pem_ file.
 .
 The _cert.pem_ and _key.pem_ files correspond to the public certificate and
 private key respectively. We need to rename them as _public.crt_ and
 _private.key_ respectively and store them under the MinIO configuration
 directory (as specified in the [MinIO
 documentation](https://min.io/docs/minio/linux/operations/network-encryption.html#enabling-tls)).
 In case you are using running a docker container as previously shown, then we
 will need to mount the folder containing the certificates as a volume;
 supposing we stored our certificates under `${HOME}/minio/certs`, we need to
 start our container as follows:
 .
 ```
 docker run -p 9000:9000 -p 9090:9090  --user $(id -u):$(id -g)  --name minio -e
 'MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE' -e
 'MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' -v
 ${HOME}/minio/data:/data -v ${HOME}/minio/certs:/certs quay.io/minio/minio
 server data --certs-dir certs --console-address ':9090'
 ```
 .
 Finally the volume configuration should then look like:
 .
 ```
 storage_manager: {
   volumes: {
     s3: {
         // Endpoint where the S3 server is located
         url: "https://localhost:9000",
 .
         // Configure TLS specific parameters
         tls: {
           root_ca_certificate:
 "/home/user/certificates/minio_certs/minica.pem",
         },
     }
   },
 ```
 .
 _Note: do not forget to modify the endpoint protocol, for instance from
 `http://localhost:9090` to `https://localhost:9090`_
 .
 ---
 .
 ## How to install it
 .
 To install the latest release of this backend library, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
 .
 - https://download.eclipse.org/zenoh/zenoh-backend-s3/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it in the same directory than `zenohd` or to any directory where it can
 find the backend library (e.g. /usr/lib or ~/.zenoh/lib)
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh-backend-s3` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 sudo apt install zenoh-backend-s3
 ```
 .
 ---
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 backend library should be
 > built with the exact same Rust version than `zenohd`. Otherwise,
 incompatibilities in memory mapping
 > of shared types between `zenohd` and the library can lead to a `"SIGSEV"`
 crash.
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 .
 ```bash
 $ zenohd --version
 zenohd v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0 (84c898d65
 2023-04-16)
 The zenoh router v0.7.0-rc-365-geca888b4-modified built with rustc 1.69.0
 (84c898d65 2023-04-16)
 ```
 .
 Here, `zenohd` has been built with the rustc version `1.69.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.69.0
 ```
 .
 And then build the backend with:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-backend-s3
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-backend-s3

Package: zenoh-bridge-dds
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 9806
Depends: libc6 (>= 2.29)
Filename: 0.7.2-rc/zenoh-bridge-dds_0.7.2-rc_amd64.deb
Size: 3117836
MD5sum: 366eba74f6d950ef253c60ae73ae49b5
SHA1: b8d547328fc5fcfa16fd7d55e721e2c0b620a674
SHA256: dd9c830c980284737765b368b7411add45cf3d57a0c2f9ba016635e49f7880a3
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for ROS2 and DDS in general
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-bridge-dds
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 8569
Depends: libc6:arm64 (>= 2.31)
Filename: 0.7.2-rc/zenoh-bridge-dds_0.7.2-rc_arm64.deb
Size: 2818956
MD5sum: c6b45d59a2f83acb48f453041a7a1721
SHA1: eee122768a34eb737f51c8b44cc4ae1e2bd078ab
SHA256: 90b7f088b482e83caec9e9a8ff9ec761c2293f2ba17cf2b57b98a7a8798a3d7c
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for ROS2 and DDS in general
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-bridge-dds
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 8591
Depends: libc6:armel (>= 2.31)
Filename: 0.7.2-rc/zenoh-bridge-dds_0.7.2-rc_armel.deb
Size: 2763840
MD5sum: f04342757da393c303c982aee696a3c4
SHA1: cab2fc4b95d4ebe01fbc9f259f6e0ac864a8c845
SHA256: e1ea01099c037356bf663f9e4095f0dd1047ac455deebe12443ecd0472f26450
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for ROS2 and DDS in general
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-bridge-dds
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 8151
Depends: libc6:armhf (>= 2.31)
Filename: 0.7.2-rc/zenoh-bridge-dds_0.7.2-rc_armhf.deb
Size: 2772860
MD5sum: f1f5c64aad44b631ce421ae166656504
SHA1: de91e2b84d3bfa1df0d165612b6ceba3e7e7b1a6
SHA256: 57f357323b67bcb143aa567e9a04a901381a435ba2ea9351a9701ca259989eff
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for ROS2 and DDS in general
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-bridge-mqtt
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 9052
Depends: libc6 (>= 2.29)
Filename: 0.7.2-rc/zenoh-bridge-mqtt_0.7.2-rc_amd64.deb
Size: 2842856
MD5sum: fc2ad30ca977af77222dd66f81744693
SHA1: bec0d2e9759a1fde7b1992379a912a62c059c167
SHA256: 9f13c602f9600090db5d533af6bbe105cf9904f7b7530cafc094f09c89ba217d
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for MQTT
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt

Package: zenoh-bridge-mqtt
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 7836
Depends: libc6:arm64 (>= 2.31)
Filename: 0.7.2-rc/zenoh-bridge-mqtt_0.7.2-rc_arm64.deb
Size: 2563844
MD5sum: 2cb80ea3c9a0f0f64a613b4df8f94e7c
SHA1: 4b3b3a0db42805ccad51386c7f6fa894c0e368e8
SHA256: b48cf4f24298f435f6f8973256ab7e57d101a6fbaa8bc776ef17f22d4a410c42
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for MQTT
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt

Package: zenoh-bridge-ros1
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 10280
Depends: libc6 (>= 2.29)
Filename: 0.7.2-rc/zenoh-bridge-ros1_0.7.2-rc_amd64.deb
Size: 3104324
MD5sum: d64ec6cdb48b6ed57b104670b5c11a33
SHA1: 991880d888bb768ece271e31c1bf17f723844c76
SHA256: 3305164fce8abd2767a10ea960647dfa0c3d36866cc31e3302c2914a06226158
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh bridge for ROS1
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-ros1
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-ros1

Package: zenoh-cpp
Version: 0.7.2.1
Architecture: x86_64
Maintainer: ZettaScale Zenoh Team, <zenoh@zettascale.tech>
Installed-Size: 110
Filename: 0.7.2-rc/zenoh-cpp-0.7.2.1.deb
Size: 15240
MD5sum: d6c01997320a695507bc036410ffd23e
SHA1: 0600786e3aeddabe064c28da27e2f72e6f2b6db8
SHA256: 3ce50ffa85e41372814bd1d627271363d34b946df08b69069526f65f351ac8cc
Section: devel
Priority: optional
Homepage: https://github.com/eclipse-zenoh/zenoh-cpp
Description: C++ bindings for Zenoh

Package: zenoh-plugin-dds
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3594
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-dds_0.7.2-rc_arm64.deb
Size: 1083120
MD5sum: 3bd38931c6a57c67fd7412c140ec85a8
SHA1: 7778d615d8890ab77cfe4fcd7733da2d380b9a67
SHA256: 7de55c9071ea13f655782814c88f11912c21bc3ced28e49196d3c3b05d93d98d
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for ROS2 and DDS in general
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 <!---
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-dds/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-dds/actions?query=workflow%3ARust)
 --->
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # DDS plugin and standalone `zenoh-bridge-dds`
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Docker image:** see [below](#Docker-image)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ## Background
 The Data Distribution Service (DDS) is a standard for data-centric publish
 subscribe. Whilst DDS has been around for quite some time and has a long
 history of deployments in various industries, it has recently gained quite a
 bit of attentions thanks to its adoption by the Robotic Operating System (ROS2)
 -- where it is used for communication between ROS2 nodes.
 .
 ## Robot Swarms and Edge Robotics
 As mentioned above, ROS2 has adopted DDS as the mechanism to exchange data
 between nodes within and potentially across a robot. That said, due to some of
 the very core assumptions at the foundations of the DDS wire-protocol, beside
 the fact that it leverages UDP/IP multicast for communication, it is not so
 straightforward to scale DDS communication over a WAN or across multiple LANs.
 Zenoh, on the other hand was designed since its inception to operate at
 Internet Scale.
 .
 ![zenoh-plugin-dds](http://zenoh.io/img/wiki/zenoh-plugin-dds.png)
 .
 Thus, the main motivations to have a **DDS plugin** for **Eclipse zenoh** are:
 .
 - Facilitate the interconnection of robot swarms.
 - Support use cases of edge robotics.
 - Give the possibility to use **zenoh**'s geo-distributed storage and query
 system to better manage robot's data.
 .
 As any plugin for Eclipse zenoh, it can be dynamically loaded by a zenoh
 router, at startup or at runtime.
 In addition, this project also provides a standalone version of this plugin as
 an executable binary named `zenoh-bridge-dds`.
 .
 ## How to install it
 .
 To install the latest release of either the DDS plugin for the Zenoh router,
 either the `zenoh-bridge-dds` standalone executable, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-plugin-dds/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download:
  - the `zenoh-plugin-dds-<version>-<platform>.zip` file for the plugin.
    Then unzip it in the same directory than `zenohd` or to any directory where
 it can find the plugin library (e.g. /usr/lib)
  - the `zenoh-bridge-dds-<version>-<platform>.zip` file for the standalone
 executable.
    Then unzip it where you want, and run the extracted `zenoh-bridge-dds`
 binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 ```
 Then either:
   - install the plugin with: `sudo apt install zenoh-plugin-dds`.
   - install the standalone executable with: `sudo apt install
 zenoh-bridge-dds`.
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 In order to build the zenoh bridge for DDS you need first to install the
 following dependencies:
 .
 - [Rust](https://www.rust-lang.org/tools/install)
 - On Linux, make sure the `llvm` and `clang` development packages are
 installed:
    - on Debians do: `sudo apt install llvm-dev libclang-dev`
    - on CentOS or RHEL do: `sudo yum install llvm-devel clang-devel`
    - on Alpine do: `apk install llvm11-dev clang-dev`
 - [CMake](https://cmake.org/download/) (to build CycloneDDS which is a native
 dependency)
 .
 Once these dependencies are in place, you may clone the repository on your
 machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-dds.git
 $ cd zenoh-plugin-dds
 ```
 > :warning: **WARNING** :warning: : On Linux, don't use `cargo build` command
 without specifying a package with `-p`. Building both `zenoh-plugin-dds`
 (plugin library) and `zenoh-bridge-dds` (standalone executable) together will
 lead to a `multiple definition of `load_plugin'` error at link time. See
 [#117](https://github.com/eclipse-zenoh/zenoh-plugin-dds/issues/117#issuecomment-1439694331)
 for explanations.
 .
 You can then choose between building the zenoh bridge for DDS:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-dds
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-dds
 ```
 The **`zenoh-bridge-dds`** binary will be generated in the `target/release`
 sub-directory.
 .
 .
 ### ROS2 package
 If you're a ROS2 user, you can also build `zenoh-bridge-dds` as a ROS package
 running:
 ```bash
 rosdep install --from-paths . --ignore-src -r -y
 colcon build --packages-select zenoh_bridge_dds --cmake-args
 -DCMAKE_BUILD_TYPE=Release
 ```
 The `rosdep` command will automatically install *Rust* and *clang* as build
 dependencies.
 .
 ## Docker image
 The **`zenoh-bridge-dds`** standalone executable is also available as a [Docker
 images](https://hub.docker.com/r/eclipse/zenoh-bridge-dds/tags?page=1&ordering=last_updated)
 for both amd64 and arm64. To get it, do:
   - `docker pull eclipse/zenoh-bridge-dds:latest` for the latest release
   - `docker pull eclipse/zenoh-bridge-dds:master` for the master branch version
 (nightly build)
 .
 :warning: **However, notice that it's usage is limited to Docker on Linux and
 using the `--net host` option.**
 The cause being that DDS uses UDP multicast and Docker doesn't support UDP
 multicast between a container and its host (see cases
 [moby/moby#23659](https://github.com/moby/moby/issues/23659),
 [moby/libnetwork#2397](https://github.com/moby/libnetwork/issues/2397) or
 [moby/libnetwork#552](https://github.com/moby/libnetwork/issues/552)). The only
 known way to make it work is to use the `--net host` option that is [only
 supported on Linux hosts](https://docs.docker.com/network/host/).
 .
 Usage: **`docker run --init --net host eclipse/zenoh-bridge-dds`**
 It supports the same command line arguments than the `zenoh-bridge-dds` (see
 below or check with `-h` argument).
 .
 ## For a quick test with ROS2 turtlesim
 Prerequisites:
  - A [ROS2 environment](http://docs.ros.org/en/galactic/Installation.html) (no
 matter the DDS implementation as soon as it implements the standard DDSI
 protocol - the default [Eclipse
 CycloneDDS](https://github.com/eclipse-cyclonedds/cyclonedds) being just fine)
  - The [turtlesim
 package](http://docs.ros.org/en/galactic/Tutorials/Turtlesim/Introducing-Turtlesim.html#install-turtlesim)
 .
 ### _1 host, 2 ROS domains_
 For a quick test on a single host, you can run the `turtlesim_node` and the
 `turtle_teleop_key` on distinct ROS domains. As soon as you run 2
 `zenoh-bridge-dds` (1 per domain) the `turtle_teleop_key` can drive the
 `turtlesim_node`.
 Here are the commands to run:
   - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
   - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
   - `./target/release/zenoh-bridge-dds -d 1`
   - `./target/release/zenoh-bridge-dds -d 2`
 .
 Notice that by default the 2 bridges will discover each other using UDP
 multicast.
 .
 ### _2 hosts, avoiding UDP multicast communication_
 By default DDS (and thus ROS2) uses UDP multicast for discovery and
 publications. But on some networks, UDP multicast is not or badly supported.
 In such cases, deploying the `zenoh-bridge-dds` on both hosts will make it to:
   - limit the DDS discovery traffic, as detailled in [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
   - route all the DDS publications made on UDP multicast by each node through
 the zenoh protocol that by default uses TCP.
 .
 Here are the commands to test this configuration with turtlesim:
   - on host 1:
     - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -d 1 -l tcp/0.0.0.0:7447`
   - on host 2:
     - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -d 2 -e tcp/<host-1-ip>:7447` - where
 `<host-1-ip>` is the IP of host 1
 .
 Notice that to avoid unwanted direct DDS communication, 2 disctinct ROS domains
 are still used.
 .
 ### _2 hosts, with an intermediate zenoh router in the cloud_
 In case your 2 hosts can't have a point-to-point communication, you could
 leverage a [zenoh
 router](https://github.com/eclipse-zenoh/zenoh#how-to-build-it) deployed in a
 cloud instance (any Linux VM will do the job). You just need to configure your
 cloud instanse with a public IP and authorize the TCP port **7447**.
 .
 :warning: the zenoh protocol is still under development leading to possible
 incompatibilities between the bridge and the router if their zenoh version
 differ. Please make sure you use a zenoh router built from a recent commit id
 from its `master` branch.
 .
 Here are the commands to test this configuration with turtlesim:
   - on cloud VM:
     - `zenohd`
   - on host 1:
     - `ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
   - on host 2:
     - `ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
 .
 Notice that there is no need to use distinct ROS domain here, since the 2 hosts
 are not supposed to directly communicate with each other.
 .
 ## More advanced usage for ROS2
 ### _Full support of ROS graph and topic lists via the forward discovery mode_
 By default the bridge doesn't route throught zenoh the DDS discovery traffic to
 the remote bridges.
 Meaning that, in case you use 2 **`zenoh-bridge-dds`** to interconnect 2 DDS
 domains, the DDS entities discovered in one domain won't be advertised in the
 other domain. Thus, the DDS data will be routed between the 2 domains only if
 matching readers and writers are declared in the 2 domains independently.
 .
 This default behaviour has an impact on ROS2 behaviour: on one side of the
 bridge the ROS graph might not reflect all the nodes from the other side of the
 bridge. The `ros2 topic list` command might not list all the topics declared on
 the other side. And the **ROS graph** is limited to the nodes in each domain.
 .
 But using the **`--fwd-discovery`** (or `-f`) option for all bridges make them
 behave differently:
  - each bridge will forward via zenoh the local DDS discovery data to the
 remote bridges (in a more compact way than the original DDS discovery traffic)
  - each bridge receiving DDS discovery data via zenoh will create a replica of
 the DDS reader or writer, with similar QoS. Those replicas will serve the route
 to/from zenoh, and will be discovered by the ROS2 nodes.
  - each bridge will forward the `ros_discovery_info` data (in a less intensive
 way than the original publications) to the remote bridges. On reception, the
 remote bridges will convert the original entities' GIDs into the GIDs of the
 corresponding replicas, and re-publish on DDS the `ros_discovery_info`. The
 full ROS graph can then be discovered by the ROS2 nodes on each host.
 ### _Limiting the ROS2 topics, services, parameters or actions to be routed_
 By default 2 zenoh bridges will route all ROS2 topics and services for which
 they detect a Writer on one side and a Reader on the other side. But you might
 want to avoid some topics and services to be routed by the bridge.
 .
 Starting `zenoh-bridge-dds` you can use the `--allow` argument to specify the
 subset of topics and services that will be routed by the bridge. This argument
 accepts a string wich is a regular expression that must match a substring of an
 allowed zenoh key (see details of [mapping of ROS2 names to zenoh
 keys](#mapping-ros2-names-to-zenoh-keys)).
 .
 Here are some examples of usage:
 | `--allow` value | allowed ROS2 communication |
 | :-- | :-- |
 | `/rosout` | `/rosout`|
 | `/rosout\|/turtle1/cmd_vel\|/turtle1/rotate_absolute` |
 `/rosout`<br>`/turtle1/cmd_vel`<br>`/turtle1/rotate_absolute` |
 | `/rosout\|/turtle1/` | `/rosout` and all `/turtle1` topics, services,
 parameters and actions |
 | `/turtle1/.*` | all topics and services with name containing `/turtle1/` |
 | `/turtle1/` | same: all topics, services, parameters and actions with name
 containing `/turtle1/` |
 | `rt/turtle1` | all topics with name containing `/turtle1` (no services,
 parameters or actions) |
 | `rq/turtle1\|/rr/turtle1` | all services and parameters with name containing
 `/turtle1` (no topics or actions) |
 | `rq/turtlesim/.*parameter\|/rr/turtlesim/.*parameter` | all parameters with
 name containing `/turtlesim` (no topics, services or actions) |
 | `rq/turtle1/.*/_action\|/rr/turtle1/.*/_action` | all actions with name
 containing `/turtle1` (no topics, services or parameters) |
 .
 ### _Running several robots without changing the ROS2 configuration_
 If you run similar robots in the same network, they will by default all us the
 same DDS topics, leading to interferences in their operations.
 A simple way to address this issue using the zenoh bridge is to:
  - deploy 1 zenoh bridge per robot
  - have each bridge started with the `--scope "/<id>"` argument, each robot
 having its own id.
  - make sure each robot cannot directly communicate via DDS with another robot
 by setting a distinct domain per robot, or configuring its network interface to
 not route UDP multicast outside the host.
 .
 Using the `--scope` option, a prefix is added to each zenoh key
 published/subscribed by the bridge (more details in [mapping of ROS2 names to
 zenoh keys](#mapping-ros2-names-to-zenoh-keys)). To interact with a robot, a
 remote ROS2 application must use a zenoh bridge configured with the same scope
 than the robot.
 .
 ### _Closer integration of ROS2 with zenoh_
 As you understood, using the zenoh bridge, each ROS2 publications and
 subscriptions are mapped to a zenoh key. Therefore, its relatively easy to
 develop an application using one of the [zenoh
 APIs](https://zenoh.io/docs/apis/apis/) to interact with one or more robot at
 the same time.
 .
 See in details how to achieve that in [this
 blog](https://zenoh.io/blog/2021-04-28-ros2-integration/).
 .
 ## Configuration
 .
 `zenoh-bridge-dds` can be configured via a JSON5 file passed via the
 `-c`argument. You can see a commented example of such configuration file:
 [`DEFAULT_CONFIG.json5`](DEFAULT_CONFIG.json5).
 .
 The `"dds"` part of this same configuration file can also be used in the
 configuration file for the zenoh router (within its `"plugins"` part). The
 router will automatically try to load the plugin library (`zenoh-plugin_dds`)
 at startup and apply its configuration.
 .
 `zenoh-bridge-dds` also accepts the following arguments. If set, each argument
 will override the similar setting from the configuration file:
  * zenoh-related arguments:
    - **`-c, --config <FILE>`** : a config file
    - **`-m, --mode <MODE>`** : The zenoh session mode. Default: `peer` Possible
 values: `peer` or `client`.
       See [zenoh
 documentation](https://zenoh.io/docs/getting-started/key-concepts/#deployment-units)
 for more details.
    - **`-l, --listen <LOCATOR>`** : A locator on which this router will listen
 for incoming sessions. Repeat this option to open several listeners. Example of
 locator: `tcp/localhost:7447`.
    - **`-e, --peer <LOCATOR>`** : A peer locator this router will try to
 connect to (typically another bridge or a zenoh router). Repeat this option to
 connect to several peers. Example of locator: `tcp/<ip-address>:7447`.
    - **`--no-multicast-scouting`** : disable the zenoh scouting protocol that
 allows automatic discovery of zenoh peers and routers.
    - **`-i, --id <hex_string>`** : The identifier (as an hexadecimal string -
 e.g.: 0A0B23...) that the zenoh bridge must use. **WARNING: this identifier
 must be unique in the system!** If not set, a random UUIDv4 will be used.
    - **`--group-member-id <ID>`** : The bridges are supervising each other via
 zenoh liveliness tokens. This option allows to set a custom identifier for the
 bridge, that will be used the liveliness token key (if not specified, the zenoh
 UUID is used).
    - **`--rest-http-port <rest-http-port>`** : set the REST API http port
 (default: 8000)
  * DDS-related arguments:
    - **`-d, --domain <ID>`** : The DDS Domain ID. By default set to `0`, or to
 `"$ROS_DOMAIN_ID"` is this environment variable is defined.
    - **`--dds-localhost-only`** : If set, the DDS discovery and traffic will
 occur only on the localhost interface (127.0.0.1).
      By default set to false, unless the "ROS_LOCALHOST_ONLY=1" environment
 variable is defined.
    - **`-f, --fwd-discovery`** : When set, rather than creating a local route
 when discovering a local DDS entity, this discovery info is forwarded to the
 remote plugins/bridges. Those will create the routes, including a replica of
 the discovered entity. More details
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
    - **`-s, --scope <String>`** : A string used as prefix to scope DDS traffic
 when mapped to zenoh keys.
    - **`-a, --allow <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must be routed via zenoh.
      By default, all partitions and topics are allowed.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
      Examples of expressions:
         - `.*/TopicA` will allow only the `TopicA` to be routed, whatever the
 partition.
         - `PartitionX/.*` will allow all the topics to be routed, but only on
 `PartitionX`.
         - `cmd_vel|rosout` will allow only the topics containing `cmd_vel` or
 `rosout` in their name or partition name to be routed.
    - **`--deny <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must NOT be routed via zenoh.
      By default, no partitions and no topics are denied.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
    - **`--max-frequency <String>...`** : specifies a maximum frequency of data
 routing over zenoh per-topic. The string must have the format `"regex=float"`
 where:
        - `"regex"` is a regular expression matching the set of
 'partition/topic-name' for which the data (per DDS instance) must be routedat
 no higher rate than associated max frequency (same syntax than --allow option).
        - `"float"` is the maximum frequency in Hertz; if publication rate is
 higher, downsampling will occur when routing.
 .
        (usable multiple times)
    - **`--queries-timeout <Duration>`**: A duration in seconds (default: 5.0
 sec) that will be used as a timeout when the bridge
      queries any other remote bridge for discovery information and for
 historical data for TRANSIENT_LOCAL DDS Readers it serves
      (i.e. if the query to the remote bridge exceed the timeout, some
 historical samples might be not routed to the Readers,
      but the route will not be blocked forever).
    - **`-w, --generalise-pub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh publications, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
    - **`-r, --generalise-sub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh subscriptions, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
 .
 ## Admin space
 .
 The zenoh bridge for DDS exposes an administration space allowing to browse the
 DDS entities that have been discovered (with their QoS), and the routes that
 have been established between DDS and zenoh.
 This administration space is accessible via any zenoh API, including the REST
 API that you can activate at `zenoh-bridge-dds` startup using the
 `--rest-http-port` argument.
 .
 The `zenoh-bridge-dds` exposes this administration space with paths prefixed by
 `@/service/<uuid>/dds` (where `<uuid>` is the unique identifier of the bridge
 instance). The informations are then organized with such paths:
  - `@/service/<uuid>/dds/version` : the bridge version
  - `@/service/<uuid>/dds/config` : the bridge configuration
  - `@/service/<uuid>/dds/participant/<gid>/reader/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/participant/<gid>/writer/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/route/from_dds/<zenoh-resource>` : a route established
 from a DDS writer to a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources)).
  - `@/service/<uuid>/dds/route/to_dds/<zenoh-resource>` : a route established
 from a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources))..
 .
 Example of queries on administration space using the REST API with the `curl`
 command line tool (don't forget to activate the REST API with `--rest-http-port
 8000` argument):
  - List all the DDS entities that have been discovered:
     ```bash
     curl http://localhost:8000/@/service/**/participant/**
     ```
  - List all established routes:
     ```bash
     curl http://localhost:8000/@/service/**/route/**
     ```
  - List all discovered DDS entities and established route for topic `cmd_vel`:
     ```bash
     curl http://localhost:8000/@/service/**/cmd_vel
     ```
 .
 > _Pro tip: pipe the result into [**jq**](https://stedolan.github.io/jq/)
 command for JSON pretty print or transformation._
 .
 ## Architecture details
 .
 Whether it's built as a library or as a standalone executable, the **zenoh
 bridge for DDS** do the same things:
 - in default mode:
   - it discovers the DDS readers and writers declared by any DDS application,
 via the standard DDS discovery protocol (that uses UDP multicast)
   - it creates a mirror DDS writer or reader for each discovered reader or
 writer (using the same QoS)
   - if maps the discovered DDS topics and partitions to zenoh keys (see mapping
 details below)
   - it forwards user's data from a DDS topic to the corresponding zenoh key,
 and vice versa
   - it does not forward to the remote bridge any DDS discovery information
 .
 - in "forward discovery" mode
   - it behaves as described
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
 ### _Mapping of DDS topics to zenoh keys_
 The mapping between DDS and zenoh is rather straightforward: given a DDS
 Reader/Writer for topic **`A`** without the partition QoS set, then the
 equivalent zenoh key will have the same name: **`A`**.
 If a partition QoS **`P`** is defined, the equivalent zenoh key will be named
 as **`P/A`**.
 .
 Optionally, the bridge can be configured with a **scope** that will be used as
 a prefix to each zenoh key.
 That is, for scope **`S`** the equivalent zenoh key will be:
  - **`S/A`** for a topic **`A`** without partition
  - **`S/P/A`** for a topic **`A`** and a partition **`P`**
 .
 ### _Mapping ROS2 names to zenoh keys_
 The mapping from ROS2 topics and services name to DDS topics is specified
 [here](https://design.ros2.org/articles/topic_and_service_names.html#mapping-of-ros-2-topic-and-service-names-to-dds-concepts).
 Notice that ROS2 does not use the DDS partitions.
 As a consequence of this mapping and of the DDS to zenoh mapping specified
 above, here are some examples of mapping from ROS2 names to zenoh keys:
 .
 | ROS2 names | DDS Topics names | zenoh keys (no scope) | zenoh keys (if
 scope="`myscope`") |
 | --- | --- | --- | --- |
 | topic: `/rosout` | `rt/rosout` | `rt/rosout` | `myscope/rt/rosout` |
 | topic: `/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` |
 `myscope/rt/turtle1/cmd_vel` |
 | service: `/turtle1/set_pen` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `myscope/rq/turtle1/set_penRequest`<br>`myscope/rr/turtle1/set_penReply` |
 | action: `/turtle1/rotate_absolute` |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `myscope/rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`myscope/rt/turtle1/rotate_absolute/_action/status`<br>`myscope/rt/turtle1/rotate_absolute/_action/feedback`
 |
 | all parameters for node `turtlesim`|
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `myscope/rq/turtlesim/list_parametersRequest`<br>`myscope/rr/turtlesim/list_parametersReply`<br>`myscope/rq/turtlesim/describe_parametersRequest`<br>`myscope/rr/turtlesim/describe_parametersReply`<br>`myscope/rq/turtlesim/get_parametersRequest`<br>`myscope/rr/turtlesim/get_parametersReply`<br>`myscope/rr/turtlesim/get_parameter_typesReply`<br>`myscope/rq/turtlesim/get_parameter_typesRequest`<br>`myscope/rq/turtlesim/set_parametersRequest`<br>`myscope/rr/turtlesim/set_parametersReply`<br>`myscope/rq/turtlesim/set_parameters_atomicallyRequest`<br>`myscope/rr/turtlesim/set_parameters_atomicallyReply`
 |
 | specific ROS discovery topic | `ros_discovery_info` | `ros_discovery_info` |
 `myscope/ros_discovery_info`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-plugin-dds
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 4022
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-dds_0.7.2-rc_amd64.deb
Size: 1226128
MD5sum: eaa8ca73e78a48aa8038c040cb03d110
SHA1: 63ac598b53c4dd9ac51dd1adb6b32f7cd583e02e
SHA256: d5a98fe2f1aa91d8a6dcd77136ca294001ca2d5854c1d1848111d627ad187e96
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for ROS2 and DDS in general
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 <!---
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-dds/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-dds/actions?query=workflow%3ARust)
 --->
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # DDS plugin and standalone `zenoh-bridge-dds`
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Docker image:** see [below](#Docker-image)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ## Background
 The Data Distribution Service (DDS) is a standard for data-centric publish
 subscribe. Whilst DDS has been around for quite some time and has a long
 history of deployments in various industries, it has recently gained quite a
 bit of attentions thanks to its adoption by the Robotic Operating System (ROS2)
 -- where it is used for communication between ROS2 nodes.
 .
 ## Robot Swarms and Edge Robotics
 As mentioned above, ROS2 has adopted DDS as the mechanism to exchange data
 between nodes within and potentially across a robot. That said, due to some of
 the very core assumptions at the foundations of the DDS wire-protocol, beside
 the fact that it leverages UDP/IP multicast for communication, it is not so
 straightforward to scale DDS communication over a WAN or across multiple LANs.
 Zenoh, on the other hand was designed since its inception to operate at
 Internet Scale.
 .
 ![zenoh-plugin-dds](http://zenoh.io/img/wiki/zenoh-plugin-dds.png)
 .
 Thus, the main motivations to have a **DDS plugin** for **Eclipse zenoh** are:
 .
 - Facilitate the interconnection of robot swarms.
 - Support use cases of edge robotics.
 - Give the possibility to use **zenoh**'s geo-distributed storage and query
 system to better manage robot's data.
 .
 As any plugin for Eclipse zenoh, it can be dynamically loaded by a zenoh
 router, at startup or at runtime.
 In addition, this project also provides a standalone version of this plugin as
 an executable binary named `zenoh-bridge-dds`.
 .
 ## How to install it
 .
 To install the latest release of either the DDS plugin for the Zenoh router,
 either the `zenoh-bridge-dds` standalone executable, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-plugin-dds/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download:
  - the `zenoh-plugin-dds-<version>-<platform>.zip` file for the plugin.
    Then unzip it in the same directory than `zenohd` or to any directory where
 it can find the plugin library (e.g. /usr/lib)
  - the `zenoh-bridge-dds-<version>-<platform>.zip` file for the standalone
 executable.
    Then unzip it where you want, and run the extracted `zenoh-bridge-dds`
 binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 ```
 Then either:
   - install the plugin with: `sudo apt install zenoh-plugin-dds`.
   - install the standalone executable with: `sudo apt install
 zenoh-bridge-dds`.
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 In order to build the zenoh bridge for DDS you need first to install the
 following dependencies:
 .
 - [Rust](https://www.rust-lang.org/tools/install)
 - On Linux, make sure the `llvm` and `clang` development packages are
 installed:
    - on Debians do: `sudo apt install llvm-dev libclang-dev`
    - on CentOS or RHEL do: `sudo yum install llvm-devel clang-devel`
    - on Alpine do: `apk install llvm11-dev clang-dev`
 - [CMake](https://cmake.org/download/) (to build CycloneDDS which is a native
 dependency)
 .
 Once these dependencies are in place, you may clone the repository on your
 machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-dds.git
 $ cd zenoh-plugin-dds
 ```
 > :warning: **WARNING** :warning: : On Linux, don't use `cargo build` command
 without specifying a package with `-p`. Building both `zenoh-plugin-dds`
 (plugin library) and `zenoh-bridge-dds` (standalone executable) together will
 lead to a `multiple definition of `load_plugin'` error at link time. See
 [#117](https://github.com/eclipse-zenoh/zenoh-plugin-dds/issues/117#issuecomment-1439694331)
 for explanations.
 .
 You can then choose between building the zenoh bridge for DDS:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-dds
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-dds
 ```
 The **`zenoh-bridge-dds`** binary will be generated in the `target/release`
 sub-directory.
 .
 .
 ### ROS2 package
 If you're a ROS2 user, you can also build `zenoh-bridge-dds` as a ROS package
 running:
 ```bash
 rosdep install --from-paths . --ignore-src -r -y
 colcon build --packages-select zenoh_bridge_dds --cmake-args
 -DCMAKE_BUILD_TYPE=Release
 ```
 The `rosdep` command will automatically install *Rust* and *clang* as build
 dependencies.
 .
 ## Docker image
 The **`zenoh-bridge-dds`** standalone executable is also available as a [Docker
 images](https://hub.docker.com/r/eclipse/zenoh-bridge-dds/tags?page=1&ordering=last_updated)
 for both amd64 and arm64. To get it, do:
   - `docker pull eclipse/zenoh-bridge-dds:latest` for the latest release
   - `docker pull eclipse/zenoh-bridge-dds:master` for the master branch version
 (nightly build)
 .
 :warning: **However, notice that it's usage is limited to Docker on Linux and
 using the `--net host` option.**
 The cause being that DDS uses UDP multicast and Docker doesn't support UDP
 multicast between a container and its host (see cases
 [moby/moby#23659](https://github.com/moby/moby/issues/23659),
 [moby/libnetwork#2397](https://github.com/moby/libnetwork/issues/2397) or
 [moby/libnetwork#552](https://github.com/moby/libnetwork/issues/552)). The only
 known way to make it work is to use the `--net host` option that is [only
 supported on Linux hosts](https://docs.docker.com/network/host/).
 .
 Usage: **`docker run --init --net host eclipse/zenoh-bridge-dds`**
 It supports the same command line arguments than the `zenoh-bridge-dds` (see
 below or check with `-h` argument).
 .
 ## For a quick test with ROS2 turtlesim
 Prerequisites:
  - A [ROS2 environment](http://docs.ros.org/en/galactic/Installation.html) (no
 matter the DDS implementation as soon as it implements the standard DDSI
 protocol - the default [Eclipse
 CycloneDDS](https://github.com/eclipse-cyclonedds/cyclonedds) being just fine)
  - The [turtlesim
 package](http://docs.ros.org/en/galactic/Tutorials/Turtlesim/Introducing-Turtlesim.html#install-turtlesim)
 .
 ### _1 host, 2 ROS domains_
 For a quick test on a single host, you can run the `turtlesim_node` and the
 `turtle_teleop_key` on distinct ROS domains. As soon as you run 2
 `zenoh-bridge-dds` (1 per domain) the `turtle_teleop_key` can drive the
 `turtlesim_node`.
 Here are the commands to run:
   - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
   - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
   - `./target/release/zenoh-bridge-dds -d 1`
   - `./target/release/zenoh-bridge-dds -d 2`
 .
 Notice that by default the 2 bridges will discover each other using UDP
 multicast.
 .
 ### _2 hosts, avoiding UDP multicast communication_
 By default DDS (and thus ROS2) uses UDP multicast for discovery and
 publications. But on some networks, UDP multicast is not or badly supported.
 In such cases, deploying the `zenoh-bridge-dds` on both hosts will make it to:
   - limit the DDS discovery traffic, as detailled in [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
   - route all the DDS publications made on UDP multicast by each node through
 the zenoh protocol that by default uses TCP.
 .
 Here are the commands to test this configuration with turtlesim:
   - on host 1:
     - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -d 1 -l tcp/0.0.0.0:7447`
   - on host 2:
     - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -d 2 -e tcp/<host-1-ip>:7447` - where
 `<host-1-ip>` is the IP of host 1
 .
 Notice that to avoid unwanted direct DDS communication, 2 disctinct ROS domains
 are still used.
 .
 ### _2 hosts, with an intermediate zenoh router in the cloud_
 In case your 2 hosts can't have a point-to-point communication, you could
 leverage a [zenoh
 router](https://github.com/eclipse-zenoh/zenoh#how-to-build-it) deployed in a
 cloud instance (any Linux VM will do the job). You just need to configure your
 cloud instanse with a public IP and authorize the TCP port **7447**.
 .
 :warning: the zenoh protocol is still under development leading to possible
 incompatibilities between the bridge and the router if their zenoh version
 differ. Please make sure you use a zenoh router built from a recent commit id
 from its `master` branch.
 .
 Here are the commands to test this configuration with turtlesim:
   - on cloud VM:
     - `zenohd`
   - on host 1:
     - `ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
   - on host 2:
     - `ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
 .
 Notice that there is no need to use distinct ROS domain here, since the 2 hosts
 are not supposed to directly communicate with each other.
 .
 ## More advanced usage for ROS2
 ### _Full support of ROS graph and topic lists via the forward discovery mode_
 By default the bridge doesn't route throught zenoh the DDS discovery traffic to
 the remote bridges.
 Meaning that, in case you use 2 **`zenoh-bridge-dds`** to interconnect 2 DDS
 domains, the DDS entities discovered in one domain won't be advertised in the
 other domain. Thus, the DDS data will be routed between the 2 domains only if
 matching readers and writers are declared in the 2 domains independently.
 .
 This default behaviour has an impact on ROS2 behaviour: on one side of the
 bridge the ROS graph might not reflect all the nodes from the other side of the
 bridge. The `ros2 topic list` command might not list all the topics declared on
 the other side. And the **ROS graph** is limited to the nodes in each domain.
 .
 But using the **`--fwd-discovery`** (or `-f`) option for all bridges make them
 behave differently:
  - each bridge will forward via zenoh the local DDS discovery data to the
 remote bridges (in a more compact way than the original DDS discovery traffic)
  - each bridge receiving DDS discovery data via zenoh will create a replica of
 the DDS reader or writer, with similar QoS. Those replicas will serve the route
 to/from zenoh, and will be discovered by the ROS2 nodes.
  - each bridge will forward the `ros_discovery_info` data (in a less intensive
 way than the original publications) to the remote bridges. On reception, the
 remote bridges will convert the original entities' GIDs into the GIDs of the
 corresponding replicas, and re-publish on DDS the `ros_discovery_info`. The
 full ROS graph can then be discovered by the ROS2 nodes on each host.
 ### _Limiting the ROS2 topics, services, parameters or actions to be routed_
 By default 2 zenoh bridges will route all ROS2 topics and services for which
 they detect a Writer on one side and a Reader on the other side. But you might
 want to avoid some topics and services to be routed by the bridge.
 .
 Starting `zenoh-bridge-dds` you can use the `--allow` argument to specify the
 subset of topics and services that will be routed by the bridge. This argument
 accepts a string wich is a regular expression that must match a substring of an
 allowed zenoh key (see details of [mapping of ROS2 names to zenoh
 keys](#mapping-ros2-names-to-zenoh-keys)).
 .
 Here are some examples of usage:
 | `--allow` value | allowed ROS2 communication |
 | :-- | :-- |
 | `/rosout` | `/rosout`|
 | `/rosout\|/turtle1/cmd_vel\|/turtle1/rotate_absolute` |
 `/rosout`<br>`/turtle1/cmd_vel`<br>`/turtle1/rotate_absolute` |
 | `/rosout\|/turtle1/` | `/rosout` and all `/turtle1` topics, services,
 parameters and actions |
 | `/turtle1/.*` | all topics and services with name containing `/turtle1/` |
 | `/turtle1/` | same: all topics, services, parameters and actions with name
 containing `/turtle1/` |
 | `rt/turtle1` | all topics with name containing `/turtle1` (no services,
 parameters or actions) |
 | `rq/turtle1\|/rr/turtle1` | all services and parameters with name containing
 `/turtle1` (no topics or actions) |
 | `rq/turtlesim/.*parameter\|/rr/turtlesim/.*parameter` | all parameters with
 name containing `/turtlesim` (no topics, services or actions) |
 | `rq/turtle1/.*/_action\|/rr/turtle1/.*/_action` | all actions with name
 containing `/turtle1` (no topics, services or parameters) |
 .
 ### _Running several robots without changing the ROS2 configuration_
 If you run similar robots in the same network, they will by default all us the
 same DDS topics, leading to interferences in their operations.
 A simple way to address this issue using the zenoh bridge is to:
  - deploy 1 zenoh bridge per robot
  - have each bridge started with the `--scope "/<id>"` argument, each robot
 having its own id.
  - make sure each robot cannot directly communicate via DDS with another robot
 by setting a distinct domain per robot, or configuring its network interface to
 not route UDP multicast outside the host.
 .
 Using the `--scope` option, a prefix is added to each zenoh key
 published/subscribed by the bridge (more details in [mapping of ROS2 names to
 zenoh keys](#mapping-ros2-names-to-zenoh-keys)). To interact with a robot, a
 remote ROS2 application must use a zenoh bridge configured with the same scope
 than the robot.
 .
 ### _Closer integration of ROS2 with zenoh_
 As you understood, using the zenoh bridge, each ROS2 publications and
 subscriptions are mapped to a zenoh key. Therefore, its relatively easy to
 develop an application using one of the [zenoh
 APIs](https://zenoh.io/docs/apis/apis/) to interact with one or more robot at
 the same time.
 .
 See in details how to achieve that in [this
 blog](https://zenoh.io/blog/2021-04-28-ros2-integration/).
 .
 ## Configuration
 .
 `zenoh-bridge-dds` can be configured via a JSON5 file passed via the
 `-c`argument. You can see a commented example of such configuration file:
 [`DEFAULT_CONFIG.json5`](DEFAULT_CONFIG.json5).
 .
 The `"dds"` part of this same configuration file can also be used in the
 configuration file for the zenoh router (within its `"plugins"` part). The
 router will automatically try to load the plugin library (`zenoh-plugin_dds`)
 at startup and apply its configuration.
 .
 `zenoh-bridge-dds` also accepts the following arguments. If set, each argument
 will override the similar setting from the configuration file:
  * zenoh-related arguments:
    - **`-c, --config <FILE>`** : a config file
    - **`-m, --mode <MODE>`** : The zenoh session mode. Default: `peer` Possible
 values: `peer` or `client`.
       See [zenoh
 documentation](https://zenoh.io/docs/getting-started/key-concepts/#deployment-units)
 for more details.
    - **`-l, --listen <LOCATOR>`** : A locator on which this router will listen
 for incoming sessions. Repeat this option to open several listeners. Example of
 locator: `tcp/localhost:7447`.
    - **`-e, --peer <LOCATOR>`** : A peer locator this router will try to
 connect to (typically another bridge or a zenoh router). Repeat this option to
 connect to several peers. Example of locator: `tcp/<ip-address>:7447`.
    - **`--no-multicast-scouting`** : disable the zenoh scouting protocol that
 allows automatic discovery of zenoh peers and routers.
    - **`-i, --id <hex_string>`** : The identifier (as an hexadecimal string -
 e.g.: 0A0B23...) that the zenoh bridge must use. **WARNING: this identifier
 must be unique in the system!** If not set, a random UUIDv4 will be used.
    - **`--group-member-id <ID>`** : The bridges are supervising each other via
 zenoh liveliness tokens. This option allows to set a custom identifier for the
 bridge, that will be used the liveliness token key (if not specified, the zenoh
 UUID is used).
    - **`--rest-http-port <rest-http-port>`** : set the REST API http port
 (default: 8000)
  * DDS-related arguments:
    - **`-d, --domain <ID>`** : The DDS Domain ID. By default set to `0`, or to
 `"$ROS_DOMAIN_ID"` is this environment variable is defined.
    - **`--dds-localhost-only`** : If set, the DDS discovery and traffic will
 occur only on the localhost interface (127.0.0.1).
      By default set to false, unless the "ROS_LOCALHOST_ONLY=1" environment
 variable is defined.
    - **`-f, --fwd-discovery`** : When set, rather than creating a local route
 when discovering a local DDS entity, this discovery info is forwarded to the
 remote plugins/bridges. Those will create the routes, including a replica of
 the discovered entity. More details
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
    - **`-s, --scope <String>`** : A string used as prefix to scope DDS traffic
 when mapped to zenoh keys.
    - **`-a, --allow <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must be routed via zenoh.
      By default, all partitions and topics are allowed.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
      Examples of expressions:
         - `.*/TopicA` will allow only the `TopicA` to be routed, whatever the
 partition.
         - `PartitionX/.*` will allow all the topics to be routed, but only on
 `PartitionX`.
         - `cmd_vel|rosout` will allow only the topics containing `cmd_vel` or
 `rosout` in their name or partition name to be routed.
    - **`--deny <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must NOT be routed via zenoh.
      By default, no partitions and no topics are denied.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
    - **`--max-frequency <String>...`** : specifies a maximum frequency of data
 routing over zenoh per-topic. The string must have the format `"regex=float"`
 where:
        - `"regex"` is a regular expression matching the set of
 'partition/topic-name' for which the data (per DDS instance) must be routedat
 no higher rate than associated max frequency (same syntax than --allow option).
        - `"float"` is the maximum frequency in Hertz; if publication rate is
 higher, downsampling will occur when routing.
 .
        (usable multiple times)
    - **`--queries-timeout <Duration>`**: A duration in seconds (default: 5.0
 sec) that will be used as a timeout when the bridge
      queries any other remote bridge for discovery information and for
 historical data for TRANSIENT_LOCAL DDS Readers it serves
      (i.e. if the query to the remote bridge exceed the timeout, some
 historical samples might be not routed to the Readers,
      but the route will not be blocked forever).
    - **`-w, --generalise-pub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh publications, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
    - **`-r, --generalise-sub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh subscriptions, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
 .
 ## Admin space
 .
 The zenoh bridge for DDS exposes an administration space allowing to browse the
 DDS entities that have been discovered (with their QoS), and the routes that
 have been established between DDS and zenoh.
 This administration space is accessible via any zenoh API, including the REST
 API that you can activate at `zenoh-bridge-dds` startup using the
 `--rest-http-port` argument.
 .
 The `zenoh-bridge-dds` exposes this administration space with paths prefixed by
 `@/service/<uuid>/dds` (where `<uuid>` is the unique identifier of the bridge
 instance). The informations are then organized with such paths:
  - `@/service/<uuid>/dds/version` : the bridge version
  - `@/service/<uuid>/dds/config` : the bridge configuration
  - `@/service/<uuid>/dds/participant/<gid>/reader/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/participant/<gid>/writer/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/route/from_dds/<zenoh-resource>` : a route established
 from a DDS writer to a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources)).
  - `@/service/<uuid>/dds/route/to_dds/<zenoh-resource>` : a route established
 from a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources))..
 .
 Example of queries on administration space using the REST API with the `curl`
 command line tool (don't forget to activate the REST API with `--rest-http-port
 8000` argument):
  - List all the DDS entities that have been discovered:
     ```bash
     curl http://localhost:8000/@/service/**/participant/**
     ```
  - List all established routes:
     ```bash
     curl http://localhost:8000/@/service/**/route/**
     ```
  - List all discovered DDS entities and established route for topic `cmd_vel`:
     ```bash
     curl http://localhost:8000/@/service/**/cmd_vel
     ```
 .
 > _Pro tip: pipe the result into [**jq**](https://stedolan.github.io/jq/)
 command for JSON pretty print or transformation._
 .
 ## Architecture details
 .
 Whether it's built as a library or as a standalone executable, the **zenoh
 bridge for DDS** do the same things:
 - in default mode:
   - it discovers the DDS readers and writers declared by any DDS application,
 via the standard DDS discovery protocol (that uses UDP multicast)
   - it creates a mirror DDS writer or reader for each discovered reader or
 writer (using the same QoS)
   - if maps the discovered DDS topics and partitions to zenoh keys (see mapping
 details below)
   - it forwards user's data from a DDS topic to the corresponding zenoh key,
 and vice versa
   - it does not forward to the remote bridge any DDS discovery information
 .
 - in "forward discovery" mode
   - it behaves as described
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
 ### _Mapping of DDS topics to zenoh keys_
 The mapping between DDS and zenoh is rather straightforward: given a DDS
 Reader/Writer for topic **`A`** without the partition QoS set, then the
 equivalent zenoh key will have the same name: **`A`**.
 If a partition QoS **`P`** is defined, the equivalent zenoh key will be named
 as **`P/A`**.
 .
 Optionally, the bridge can be configured with a **scope** that will be used as
 a prefix to each zenoh key.
 That is, for scope **`S`** the equivalent zenoh key will be:
  - **`S/A`** for a topic **`A`** without partition
  - **`S/P/A`** for a topic **`A`** and a partition **`P`**
 .
 ### _Mapping ROS2 names to zenoh keys_
 The mapping from ROS2 topics and services name to DDS topics is specified
 [here](https://design.ros2.org/articles/topic_and_service_names.html#mapping-of-ros-2-topic-and-service-names-to-dds-concepts).
 Notice that ROS2 does not use the DDS partitions.
 As a consequence of this mapping and of the DDS to zenoh mapping specified
 above, here are some examples of mapping from ROS2 names to zenoh keys:
 .
 | ROS2 names | DDS Topics names | zenoh keys (no scope) | zenoh keys (if
 scope="`myscope`") |
 | --- | --- | --- | --- |
 | topic: `/rosout` | `rt/rosout` | `rt/rosout` | `myscope/rt/rosout` |
 | topic: `/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` |
 `myscope/rt/turtle1/cmd_vel` |
 | service: `/turtle1/set_pen` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `myscope/rq/turtle1/set_penRequest`<br>`myscope/rr/turtle1/set_penReply` |
 | action: `/turtle1/rotate_absolute` |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `myscope/rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`myscope/rt/turtle1/rotate_absolute/_action/status`<br>`myscope/rt/turtle1/rotate_absolute/_action/feedback`
 |
 | all parameters for node `turtlesim`|
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `myscope/rq/turtlesim/list_parametersRequest`<br>`myscope/rr/turtlesim/list_parametersReply`<br>`myscope/rq/turtlesim/describe_parametersRequest`<br>`myscope/rr/turtlesim/describe_parametersReply`<br>`myscope/rq/turtlesim/get_parametersRequest`<br>`myscope/rr/turtlesim/get_parametersReply`<br>`myscope/rr/turtlesim/get_parameter_typesReply`<br>`myscope/rq/turtlesim/get_parameter_typesRequest`<br>`myscope/rq/turtlesim/set_parametersRequest`<br>`myscope/rr/turtlesim/set_parametersReply`<br>`myscope/rq/turtlesim/set_parameters_atomicallyRequest`<br>`myscope/rr/turtlesim/set_parameters_atomicallyReply`
 |
 | specific ROS discovery topic | `ros_discovery_info` | `ros_discovery_info` |
 `myscope/ros_discovery_info`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-plugin-dds
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3429
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-dds_0.7.2-rc_armel.deb
Size: 1063248
MD5sum: 5bdcbbf092d53bf96348ae6bb70b8b27
SHA1: a16037515282466e6b7ed53fcefa1981d8d9acd2
SHA256: 1e463fc49e80555576d494c4758bd6c5fe8b55a6bc5f1919495f243c42e36322
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for ROS2 and DDS in general
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 <!---
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-dds/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-dds/actions?query=workflow%3ARust)
 --->
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # DDS plugin and standalone `zenoh-bridge-dds`
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Docker image:** see [below](#Docker-image)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ## Background
 The Data Distribution Service (DDS) is a standard for data-centric publish
 subscribe. Whilst DDS has been around for quite some time and has a long
 history of deployments in various industries, it has recently gained quite a
 bit of attentions thanks to its adoption by the Robotic Operating System (ROS2)
 -- where it is used for communication between ROS2 nodes.
 .
 ## Robot Swarms and Edge Robotics
 As mentioned above, ROS2 has adopted DDS as the mechanism to exchange data
 between nodes within and potentially across a robot. That said, due to some of
 the very core assumptions at the foundations of the DDS wire-protocol, beside
 the fact that it leverages UDP/IP multicast for communication, it is not so
 straightforward to scale DDS communication over a WAN or across multiple LANs.
 Zenoh, on the other hand was designed since its inception to operate at
 Internet Scale.
 .
 ![zenoh-plugin-dds](http://zenoh.io/img/wiki/zenoh-plugin-dds.png)
 .
 Thus, the main motivations to have a **DDS plugin** for **Eclipse zenoh** are:
 .
 - Facilitate the interconnection of robot swarms.
 - Support use cases of edge robotics.
 - Give the possibility to use **zenoh**'s geo-distributed storage and query
 system to better manage robot's data.
 .
 As any plugin for Eclipse zenoh, it can be dynamically loaded by a zenoh
 router, at startup or at runtime.
 In addition, this project also provides a standalone version of this plugin as
 an executable binary named `zenoh-bridge-dds`.
 .
 ## How to install it
 .
 To install the latest release of either the DDS plugin for the Zenoh router,
 either the `zenoh-bridge-dds` standalone executable, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-plugin-dds/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download:
  - the `zenoh-plugin-dds-<version>-<platform>.zip` file for the plugin.
    Then unzip it in the same directory than `zenohd` or to any directory where
 it can find the plugin library (e.g. /usr/lib)
  - the `zenoh-bridge-dds-<version>-<platform>.zip` file for the standalone
 executable.
    Then unzip it where you want, and run the extracted `zenoh-bridge-dds`
 binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 ```
 Then either:
   - install the plugin with: `sudo apt install zenoh-plugin-dds`.
   - install the standalone executable with: `sudo apt install
 zenoh-bridge-dds`.
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 In order to build the zenoh bridge for DDS you need first to install the
 following dependencies:
 .
 - [Rust](https://www.rust-lang.org/tools/install)
 - On Linux, make sure the `llvm` and `clang` development packages are
 installed:
    - on Debians do: `sudo apt install llvm-dev libclang-dev`
    - on CentOS or RHEL do: `sudo yum install llvm-devel clang-devel`
    - on Alpine do: `apk install llvm11-dev clang-dev`
 - [CMake](https://cmake.org/download/) (to build CycloneDDS which is a native
 dependency)
 .
 Once these dependencies are in place, you may clone the repository on your
 machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-dds.git
 $ cd zenoh-plugin-dds
 ```
 > :warning: **WARNING** :warning: : On Linux, don't use `cargo build` command
 without specifying a package with `-p`. Building both `zenoh-plugin-dds`
 (plugin library) and `zenoh-bridge-dds` (standalone executable) together will
 lead to a `multiple definition of `load_plugin'` error at link time. See
 [#117](https://github.com/eclipse-zenoh/zenoh-plugin-dds/issues/117#issuecomment-1439694331)
 for explanations.
 .
 You can then choose between building the zenoh bridge for DDS:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-dds
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-dds
 ```
 The **`zenoh-bridge-dds`** binary will be generated in the `target/release`
 sub-directory.
 .
 .
 ### ROS2 package
 If you're a ROS2 user, you can also build `zenoh-bridge-dds` as a ROS package
 running:
 ```bash
 rosdep install --from-paths . --ignore-src -r -y
 colcon build --packages-select zenoh_bridge_dds --cmake-args
 -DCMAKE_BUILD_TYPE=Release
 ```
 The `rosdep` command will automatically install *Rust* and *clang* as build
 dependencies.
 .
 ## Docker image
 The **`zenoh-bridge-dds`** standalone executable is also available as a [Docker
 images](https://hub.docker.com/r/eclipse/zenoh-bridge-dds/tags?page=1&ordering=last_updated)
 for both amd64 and arm64. To get it, do:
   - `docker pull eclipse/zenoh-bridge-dds:latest` for the latest release
   - `docker pull eclipse/zenoh-bridge-dds:master` for the master branch version
 (nightly build)
 .
 :warning: **However, notice that it's usage is limited to Docker on Linux and
 using the `--net host` option.**
 The cause being that DDS uses UDP multicast and Docker doesn't support UDP
 multicast between a container and its host (see cases
 [moby/moby#23659](https://github.com/moby/moby/issues/23659),
 [moby/libnetwork#2397](https://github.com/moby/libnetwork/issues/2397) or
 [moby/libnetwork#552](https://github.com/moby/libnetwork/issues/552)). The only
 known way to make it work is to use the `--net host` option that is [only
 supported on Linux hosts](https://docs.docker.com/network/host/).
 .
 Usage: **`docker run --init --net host eclipse/zenoh-bridge-dds`**
 It supports the same command line arguments than the `zenoh-bridge-dds` (see
 below or check with `-h` argument).
 .
 ## For a quick test with ROS2 turtlesim
 Prerequisites:
  - A [ROS2 environment](http://docs.ros.org/en/galactic/Installation.html) (no
 matter the DDS implementation as soon as it implements the standard DDSI
 protocol - the default [Eclipse
 CycloneDDS](https://github.com/eclipse-cyclonedds/cyclonedds) being just fine)
  - The [turtlesim
 package](http://docs.ros.org/en/galactic/Tutorials/Turtlesim/Introducing-Turtlesim.html#install-turtlesim)
 .
 ### _1 host, 2 ROS domains_
 For a quick test on a single host, you can run the `turtlesim_node` and the
 `turtle_teleop_key` on distinct ROS domains. As soon as you run 2
 `zenoh-bridge-dds` (1 per domain) the `turtle_teleop_key` can drive the
 `turtlesim_node`.
 Here are the commands to run:
   - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
   - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
   - `./target/release/zenoh-bridge-dds -d 1`
   - `./target/release/zenoh-bridge-dds -d 2`
 .
 Notice that by default the 2 bridges will discover each other using UDP
 multicast.
 .
 ### _2 hosts, avoiding UDP multicast communication_
 By default DDS (and thus ROS2) uses UDP multicast for discovery and
 publications. But on some networks, UDP multicast is not or badly supported.
 In such cases, deploying the `zenoh-bridge-dds` on both hosts will make it to:
   - limit the DDS discovery traffic, as detailled in [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
   - route all the DDS publications made on UDP multicast by each node through
 the zenoh protocol that by default uses TCP.
 .
 Here are the commands to test this configuration with turtlesim:
   - on host 1:
     - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -d 1 -l tcp/0.0.0.0:7447`
   - on host 2:
     - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -d 2 -e tcp/<host-1-ip>:7447` - where
 `<host-1-ip>` is the IP of host 1
 .
 Notice that to avoid unwanted direct DDS communication, 2 disctinct ROS domains
 are still used.
 .
 ### _2 hosts, with an intermediate zenoh router in the cloud_
 In case your 2 hosts can't have a point-to-point communication, you could
 leverage a [zenoh
 router](https://github.com/eclipse-zenoh/zenoh#how-to-build-it) deployed in a
 cloud instance (any Linux VM will do the job). You just need to configure your
 cloud instanse with a public IP and authorize the TCP port **7447**.
 .
 :warning: the zenoh protocol is still under development leading to possible
 incompatibilities between the bridge and the router if their zenoh version
 differ. Please make sure you use a zenoh router built from a recent commit id
 from its `master` branch.
 .
 Here are the commands to test this configuration with turtlesim:
   - on cloud VM:
     - `zenohd`
   - on host 1:
     - `ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
   - on host 2:
     - `ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
 .
 Notice that there is no need to use distinct ROS domain here, since the 2 hosts
 are not supposed to directly communicate with each other.
 .
 ## More advanced usage for ROS2
 ### _Full support of ROS graph and topic lists via the forward discovery mode_
 By default the bridge doesn't route throught zenoh the DDS discovery traffic to
 the remote bridges.
 Meaning that, in case you use 2 **`zenoh-bridge-dds`** to interconnect 2 DDS
 domains, the DDS entities discovered in one domain won't be advertised in the
 other domain. Thus, the DDS data will be routed between the 2 domains only if
 matching readers and writers are declared in the 2 domains independently.
 .
 This default behaviour has an impact on ROS2 behaviour: on one side of the
 bridge the ROS graph might not reflect all the nodes from the other side of the
 bridge. The `ros2 topic list` command might not list all the topics declared on
 the other side. And the **ROS graph** is limited to the nodes in each domain.
 .
 But using the **`--fwd-discovery`** (or `-f`) option for all bridges make them
 behave differently:
  - each bridge will forward via zenoh the local DDS discovery data to the
 remote bridges (in a more compact way than the original DDS discovery traffic)
  - each bridge receiving DDS discovery data via zenoh will create a replica of
 the DDS reader or writer, with similar QoS. Those replicas will serve the route
 to/from zenoh, and will be discovered by the ROS2 nodes.
  - each bridge will forward the `ros_discovery_info` data (in a less intensive
 way than the original publications) to the remote bridges. On reception, the
 remote bridges will convert the original entities' GIDs into the GIDs of the
 corresponding replicas, and re-publish on DDS the `ros_discovery_info`. The
 full ROS graph can then be discovered by the ROS2 nodes on each host.
 ### _Limiting the ROS2 topics, services, parameters or actions to be routed_
 By default 2 zenoh bridges will route all ROS2 topics and services for which
 they detect a Writer on one side and a Reader on the other side. But you might
 want to avoid some topics and services to be routed by the bridge.
 .
 Starting `zenoh-bridge-dds` you can use the `--allow` argument to specify the
 subset of topics and services that will be routed by the bridge. This argument
 accepts a string wich is a regular expression that must match a substring of an
 allowed zenoh key (see details of [mapping of ROS2 names to zenoh
 keys](#mapping-ros2-names-to-zenoh-keys)).
 .
 Here are some examples of usage:
 | `--allow` value | allowed ROS2 communication |
 | :-- | :-- |
 | `/rosout` | `/rosout`|
 | `/rosout\|/turtle1/cmd_vel\|/turtle1/rotate_absolute` |
 `/rosout`<br>`/turtle1/cmd_vel`<br>`/turtle1/rotate_absolute` |
 | `/rosout\|/turtle1/` | `/rosout` and all `/turtle1` topics, services,
 parameters and actions |
 | `/turtle1/.*` | all topics and services with name containing `/turtle1/` |
 | `/turtle1/` | same: all topics, services, parameters and actions with name
 containing `/turtle1/` |
 | `rt/turtle1` | all topics with name containing `/turtle1` (no services,
 parameters or actions) |
 | `rq/turtle1\|/rr/turtle1` | all services and parameters with name containing
 `/turtle1` (no topics or actions) |
 | `rq/turtlesim/.*parameter\|/rr/turtlesim/.*parameter` | all parameters with
 name containing `/turtlesim` (no topics, services or actions) |
 | `rq/turtle1/.*/_action\|/rr/turtle1/.*/_action` | all actions with name
 containing `/turtle1` (no topics, services or parameters) |
 .
 ### _Running several robots without changing the ROS2 configuration_
 If you run similar robots in the same network, they will by default all us the
 same DDS topics, leading to interferences in their operations.
 A simple way to address this issue using the zenoh bridge is to:
  - deploy 1 zenoh bridge per robot
  - have each bridge started with the `--scope "/<id>"` argument, each robot
 having its own id.
  - make sure each robot cannot directly communicate via DDS with another robot
 by setting a distinct domain per robot, or configuring its network interface to
 not route UDP multicast outside the host.
 .
 Using the `--scope` option, a prefix is added to each zenoh key
 published/subscribed by the bridge (more details in [mapping of ROS2 names to
 zenoh keys](#mapping-ros2-names-to-zenoh-keys)). To interact with a robot, a
 remote ROS2 application must use a zenoh bridge configured with the same scope
 than the robot.
 .
 ### _Closer integration of ROS2 with zenoh_
 As you understood, using the zenoh bridge, each ROS2 publications and
 subscriptions are mapped to a zenoh key. Therefore, its relatively easy to
 develop an application using one of the [zenoh
 APIs](https://zenoh.io/docs/apis/apis/) to interact with one or more robot at
 the same time.
 .
 See in details how to achieve that in [this
 blog](https://zenoh.io/blog/2021-04-28-ros2-integration/).
 .
 ## Configuration
 .
 `zenoh-bridge-dds` can be configured via a JSON5 file passed via the
 `-c`argument. You can see a commented example of such configuration file:
 [`DEFAULT_CONFIG.json5`](DEFAULT_CONFIG.json5).
 .
 The `"dds"` part of this same configuration file can also be used in the
 configuration file for the zenoh router (within its `"plugins"` part). The
 router will automatically try to load the plugin library (`zenoh-plugin_dds`)
 at startup and apply its configuration.
 .
 `zenoh-bridge-dds` also accepts the following arguments. If set, each argument
 will override the similar setting from the configuration file:
  * zenoh-related arguments:
    - **`-c, --config <FILE>`** : a config file
    - **`-m, --mode <MODE>`** : The zenoh session mode. Default: `peer` Possible
 values: `peer` or `client`.
       See [zenoh
 documentation](https://zenoh.io/docs/getting-started/key-concepts/#deployment-units)
 for more details.
    - **`-l, --listen <LOCATOR>`** : A locator on which this router will listen
 for incoming sessions. Repeat this option to open several listeners. Example of
 locator: `tcp/localhost:7447`.
    - **`-e, --peer <LOCATOR>`** : A peer locator this router will try to
 connect to (typically another bridge or a zenoh router). Repeat this option to
 connect to several peers. Example of locator: `tcp/<ip-address>:7447`.
    - **`--no-multicast-scouting`** : disable the zenoh scouting protocol that
 allows automatic discovery of zenoh peers and routers.
    - **`-i, --id <hex_string>`** : The identifier (as an hexadecimal string -
 e.g.: 0A0B23...) that the zenoh bridge must use. **WARNING: this identifier
 must be unique in the system!** If not set, a random UUIDv4 will be used.
    - **`--group-member-id <ID>`** : The bridges are supervising each other via
 zenoh liveliness tokens. This option allows to set a custom identifier for the
 bridge, that will be used the liveliness token key (if not specified, the zenoh
 UUID is used).
    - **`--rest-http-port <rest-http-port>`** : set the REST API http port
 (default: 8000)
  * DDS-related arguments:
    - **`-d, --domain <ID>`** : The DDS Domain ID. By default set to `0`, or to
 `"$ROS_DOMAIN_ID"` is this environment variable is defined.
    - **`--dds-localhost-only`** : If set, the DDS discovery and traffic will
 occur only on the localhost interface (127.0.0.1).
      By default set to false, unless the "ROS_LOCALHOST_ONLY=1" environment
 variable is defined.
    - **`-f, --fwd-discovery`** : When set, rather than creating a local route
 when discovering a local DDS entity, this discovery info is forwarded to the
 remote plugins/bridges. Those will create the routes, including a replica of
 the discovered entity. More details
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
    - **`-s, --scope <String>`** : A string used as prefix to scope DDS traffic
 when mapped to zenoh keys.
    - **`-a, --allow <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must be routed via zenoh.
      By default, all partitions and topics are allowed.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
      Examples of expressions:
         - `.*/TopicA` will allow only the `TopicA` to be routed, whatever the
 partition.
         - `PartitionX/.*` will allow all the topics to be routed, but only on
 `PartitionX`.
         - `cmd_vel|rosout` will allow only the topics containing `cmd_vel` or
 `rosout` in their name or partition name to be routed.
    - **`--deny <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must NOT be routed via zenoh.
      By default, no partitions and no topics are denied.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
    - **`--max-frequency <String>...`** : specifies a maximum frequency of data
 routing over zenoh per-topic. The string must have the format `"regex=float"`
 where:
        - `"regex"` is a regular expression matching the set of
 'partition/topic-name' for which the data (per DDS instance) must be routedat
 no higher rate than associated max frequency (same syntax than --allow option).
        - `"float"` is the maximum frequency in Hertz; if publication rate is
 higher, downsampling will occur when routing.
 .
        (usable multiple times)
    - **`--queries-timeout <Duration>`**: A duration in seconds (default: 5.0
 sec) that will be used as a timeout when the bridge
      queries any other remote bridge for discovery information and for
 historical data for TRANSIENT_LOCAL DDS Readers it serves
      (i.e. if the query to the remote bridge exceed the timeout, some
 historical samples might be not routed to the Readers,
      but the route will not be blocked forever).
    - **`-w, --generalise-pub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh publications, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
    - **`-r, --generalise-sub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh subscriptions, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
 .
 ## Admin space
 .
 The zenoh bridge for DDS exposes an administration space allowing to browse the
 DDS entities that have been discovered (with their QoS), and the routes that
 have been established between DDS and zenoh.
 This administration space is accessible via any zenoh API, including the REST
 API that you can activate at `zenoh-bridge-dds` startup using the
 `--rest-http-port` argument.
 .
 The `zenoh-bridge-dds` exposes this administration space with paths prefixed by
 `@/service/<uuid>/dds` (where `<uuid>` is the unique identifier of the bridge
 instance). The informations are then organized with such paths:
  - `@/service/<uuid>/dds/version` : the bridge version
  - `@/service/<uuid>/dds/config` : the bridge configuration
  - `@/service/<uuid>/dds/participant/<gid>/reader/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/participant/<gid>/writer/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/route/from_dds/<zenoh-resource>` : a route established
 from a DDS writer to a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources)).
  - `@/service/<uuid>/dds/route/to_dds/<zenoh-resource>` : a route established
 from a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources))..
 .
 Example of queries on administration space using the REST API with the `curl`
 command line tool (don't forget to activate the REST API with `--rest-http-port
 8000` argument):
  - List all the DDS entities that have been discovered:
     ```bash
     curl http://localhost:8000/@/service/**/participant/**
     ```
  - List all established routes:
     ```bash
     curl http://localhost:8000/@/service/**/route/**
     ```
  - List all discovered DDS entities and established route for topic `cmd_vel`:
     ```bash
     curl http://localhost:8000/@/service/**/cmd_vel
     ```
 .
 > _Pro tip: pipe the result into [**jq**](https://stedolan.github.io/jq/)
 command for JSON pretty print or transformation._
 .
 ## Architecture details
 .
 Whether it's built as a library or as a standalone executable, the **zenoh
 bridge for DDS** do the same things:
 - in default mode:
   - it discovers the DDS readers and writers declared by any DDS application,
 via the standard DDS discovery protocol (that uses UDP multicast)
   - it creates a mirror DDS writer or reader for each discovered reader or
 writer (using the same QoS)
   - if maps the discovered DDS topics and partitions to zenoh keys (see mapping
 details below)
   - it forwards user's data from a DDS topic to the corresponding zenoh key,
 and vice versa
   - it does not forward to the remote bridge any DDS discovery information
 .
 - in "forward discovery" mode
   - it behaves as described
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
 ### _Mapping of DDS topics to zenoh keys_
 The mapping between DDS and zenoh is rather straightforward: given a DDS
 Reader/Writer for topic **`A`** without the partition QoS set, then the
 equivalent zenoh key will have the same name: **`A`**.
 If a partition QoS **`P`** is defined, the equivalent zenoh key will be named
 as **`P/A`**.
 .
 Optionally, the bridge can be configured with a **scope** that will be used as
 a prefix to each zenoh key.
 That is, for scope **`S`** the equivalent zenoh key will be:
  - **`S/A`** for a topic **`A`** without partition
  - **`S/P/A`** for a topic **`A`** and a partition **`P`**
 .
 ### _Mapping ROS2 names to zenoh keys_
 The mapping from ROS2 topics and services name to DDS topics is specified
 [here](https://design.ros2.org/articles/topic_and_service_names.html#mapping-of-ros-2-topic-and-service-names-to-dds-concepts).
 Notice that ROS2 does not use the DDS partitions.
 As a consequence of this mapping and of the DDS to zenoh mapping specified
 above, here are some examples of mapping from ROS2 names to zenoh keys:
 .
 | ROS2 names | DDS Topics names | zenoh keys (no scope) | zenoh keys (if
 scope="`myscope`") |
 | --- | --- | --- | --- |
 | topic: `/rosout` | `rt/rosout` | `rt/rosout` | `myscope/rt/rosout` |
 | topic: `/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` |
 `myscope/rt/turtle1/cmd_vel` |
 | service: `/turtle1/set_pen` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `myscope/rq/turtle1/set_penRequest`<br>`myscope/rr/turtle1/set_penReply` |
 | action: `/turtle1/rotate_absolute` |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `myscope/rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`myscope/rt/turtle1/rotate_absolute/_action/status`<br>`myscope/rt/turtle1/rotate_absolute/_action/feedback`
 |
 | all parameters for node `turtlesim`|
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `myscope/rq/turtlesim/list_parametersRequest`<br>`myscope/rr/turtlesim/list_parametersReply`<br>`myscope/rq/turtlesim/describe_parametersRequest`<br>`myscope/rr/turtlesim/describe_parametersReply`<br>`myscope/rq/turtlesim/get_parametersRequest`<br>`myscope/rr/turtlesim/get_parametersReply`<br>`myscope/rr/turtlesim/get_parameter_typesReply`<br>`myscope/rq/turtlesim/get_parameter_typesRequest`<br>`myscope/rq/turtlesim/set_parametersRequest`<br>`myscope/rr/turtlesim/set_parametersReply`<br>`myscope/rq/turtlesim/set_parameters_atomicallyRequest`<br>`myscope/rr/turtlesim/set_parameters_atomicallyReply`
 |
 | specific ROS discovery topic | `ros_discovery_info` | `ros_discovery_info` |
 `myscope/ros_discovery_info`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-plugin-dds
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3149
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-dds_0.7.2-rc_armhf.deb
Size: 1069892
MD5sum: 5ef5d5167aabdef96aade74717382dd7
SHA1: ff4f2f043cdf8780115930aab22d34dafbecf8fe
SHA256: aa2a5303bfed9df42a8f937a4e924dea61807347ee9b98abfa349a7dda633695
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for ROS2 and DDS in general
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 <!---
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-dds/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-dds/actions?query=workflow%3ARust)
 --->
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # DDS plugin and standalone `zenoh-bridge-dds`
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Docker image:** see [below](#Docker-image)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ## Background
 The Data Distribution Service (DDS) is a standard for data-centric publish
 subscribe. Whilst DDS has been around for quite some time and has a long
 history of deployments in various industries, it has recently gained quite a
 bit of attentions thanks to its adoption by the Robotic Operating System (ROS2)
 -- where it is used for communication between ROS2 nodes.
 .
 ## Robot Swarms and Edge Robotics
 As mentioned above, ROS2 has adopted DDS as the mechanism to exchange data
 between nodes within and potentially across a robot. That said, due to some of
 the very core assumptions at the foundations of the DDS wire-protocol, beside
 the fact that it leverages UDP/IP multicast for communication, it is not so
 straightforward to scale DDS communication over a WAN or across multiple LANs.
 Zenoh, on the other hand was designed since its inception to operate at
 Internet Scale.
 .
 ![zenoh-plugin-dds](http://zenoh.io/img/wiki/zenoh-plugin-dds.png)
 .
 Thus, the main motivations to have a **DDS plugin** for **Eclipse zenoh** are:
 .
 - Facilitate the interconnection of robot swarms.
 - Support use cases of edge robotics.
 - Give the possibility to use **zenoh**'s geo-distributed storage and query
 system to better manage robot's data.
 .
 As any plugin for Eclipse zenoh, it can be dynamically loaded by a zenoh
 router, at startup or at runtime.
 In addition, this project also provides a standalone version of this plugin as
 an executable binary named `zenoh-bridge-dds`.
 .
 ## How to install it
 .
 To install the latest release of either the DDS plugin for the Zenoh router,
 either the `zenoh-bridge-dds` standalone executable, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-plugin-dds/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download:
  - the `zenoh-plugin-dds-<version>-<platform>.zip` file for the plugin.
    Then unzip it in the same directory than `zenohd` or to any directory where
 it can find the plugin library (e.g. /usr/lib)
  - the `zenoh-bridge-dds-<version>-<platform>.zip` file for the standalone
 executable.
    Then unzip it where you want, and run the extracted `zenoh-bridge-dds`
 binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 ```
 Then either:
   - install the plugin with: `sudo apt install zenoh-plugin-dds`.
   - install the standalone executable with: `sudo apt install
 zenoh-bridge-dds`.
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 In order to build the zenoh bridge for DDS you need first to install the
 following dependencies:
 .
 - [Rust](https://www.rust-lang.org/tools/install)
 - On Linux, make sure the `llvm` and `clang` development packages are
 installed:
    - on Debians do: `sudo apt install llvm-dev libclang-dev`
    - on CentOS or RHEL do: `sudo yum install llvm-devel clang-devel`
    - on Alpine do: `apk install llvm11-dev clang-dev`
 - [CMake](https://cmake.org/download/) (to build CycloneDDS which is a native
 dependency)
 .
 Once these dependencies are in place, you may clone the repository on your
 machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-dds.git
 $ cd zenoh-plugin-dds
 ```
 > :warning: **WARNING** :warning: : On Linux, don't use `cargo build` command
 without specifying a package with `-p`. Building both `zenoh-plugin-dds`
 (plugin library) and `zenoh-bridge-dds` (standalone executable) together will
 lead to a `multiple definition of `load_plugin'` error at link time. See
 [#117](https://github.com/eclipse-zenoh/zenoh-plugin-dds/issues/117#issuecomment-1439694331)
 for explanations.
 .
 You can then choose between building the zenoh bridge for DDS:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-dds
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-dds
 ```
 The **`zenoh-bridge-dds`** binary will be generated in the `target/release`
 sub-directory.
 .
 .
 ### ROS2 package
 If you're a ROS2 user, you can also build `zenoh-bridge-dds` as a ROS package
 running:
 ```bash
 rosdep install --from-paths . --ignore-src -r -y
 colcon build --packages-select zenoh_bridge_dds --cmake-args
 -DCMAKE_BUILD_TYPE=Release
 ```
 The `rosdep` command will automatically install *Rust* and *clang* as build
 dependencies.
 .
 ## Docker image
 The **`zenoh-bridge-dds`** standalone executable is also available as a [Docker
 images](https://hub.docker.com/r/eclipse/zenoh-bridge-dds/tags?page=1&ordering=last_updated)
 for both amd64 and arm64. To get it, do:
   - `docker pull eclipse/zenoh-bridge-dds:latest` for the latest release
   - `docker pull eclipse/zenoh-bridge-dds:master` for the master branch version
 (nightly build)
 .
 :warning: **However, notice that it's usage is limited to Docker on Linux and
 using the `--net host` option.**
 The cause being that DDS uses UDP multicast and Docker doesn't support UDP
 multicast between a container and its host (see cases
 [moby/moby#23659](https://github.com/moby/moby/issues/23659),
 [moby/libnetwork#2397](https://github.com/moby/libnetwork/issues/2397) or
 [moby/libnetwork#552](https://github.com/moby/libnetwork/issues/552)). The only
 known way to make it work is to use the `--net host` option that is [only
 supported on Linux hosts](https://docs.docker.com/network/host/).
 .
 Usage: **`docker run --init --net host eclipse/zenoh-bridge-dds`**
 It supports the same command line arguments than the `zenoh-bridge-dds` (see
 below or check with `-h` argument).
 .
 ## For a quick test with ROS2 turtlesim
 Prerequisites:
  - A [ROS2 environment](http://docs.ros.org/en/galactic/Installation.html) (no
 matter the DDS implementation as soon as it implements the standard DDSI
 protocol - the default [Eclipse
 CycloneDDS](https://github.com/eclipse-cyclonedds/cyclonedds) being just fine)
  - The [turtlesim
 package](http://docs.ros.org/en/galactic/Tutorials/Turtlesim/Introducing-Turtlesim.html#install-turtlesim)
 .
 ### _1 host, 2 ROS domains_
 For a quick test on a single host, you can run the `turtlesim_node` and the
 `turtle_teleop_key` on distinct ROS domains. As soon as you run 2
 `zenoh-bridge-dds` (1 per domain) the `turtle_teleop_key` can drive the
 `turtlesim_node`.
 Here are the commands to run:
   - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
   - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
   - `./target/release/zenoh-bridge-dds -d 1`
   - `./target/release/zenoh-bridge-dds -d 2`
 .
 Notice that by default the 2 bridges will discover each other using UDP
 multicast.
 .
 ### _2 hosts, avoiding UDP multicast communication_
 By default DDS (and thus ROS2) uses UDP multicast for discovery and
 publications. But on some networks, UDP multicast is not or badly supported.
 In such cases, deploying the `zenoh-bridge-dds` on both hosts will make it to:
   - limit the DDS discovery traffic, as detailled in [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
   - route all the DDS publications made on UDP multicast by each node through
 the zenoh protocol that by default uses TCP.
 .
 Here are the commands to test this configuration with turtlesim:
   - on host 1:
     - `ROS_DOMAIN_ID=1 ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -d 1 -l tcp/0.0.0.0:7447`
   - on host 2:
     - `ROS_DOMAIN_ID=2 ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -d 2 -e tcp/<host-1-ip>:7447` - where
 `<host-1-ip>` is the IP of host 1
 .
 Notice that to avoid unwanted direct DDS communication, 2 disctinct ROS domains
 are still used.
 .
 ### _2 hosts, with an intermediate zenoh router in the cloud_
 In case your 2 hosts can't have a point-to-point communication, you could
 leverage a [zenoh
 router](https://github.com/eclipse-zenoh/zenoh#how-to-build-it) deployed in a
 cloud instance (any Linux VM will do the job). You just need to configure your
 cloud instanse with a public IP and authorize the TCP port **7447**.
 .
 :warning: the zenoh protocol is still under development leading to possible
 incompatibilities between the bridge and the router if their zenoh version
 differ. Please make sure you use a zenoh router built from a recent commit id
 from its `master` branch.
 .
 Here are the commands to test this configuration with turtlesim:
   - on cloud VM:
     - `zenohd`
   - on host 1:
     - `ros2 run turtlesim turtlesim_node`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
   - on host 2:
     - `ros2 run turtlesim turtle_teleop_key`
     - `./target/release/zenoh-bridge-dds -e tcp/<cloud-ip>:7447`
       _where `<cloud-ip>` is the IP of your cloud instance_
 .
 Notice that there is no need to use distinct ROS domain here, since the 2 hosts
 are not supposed to directly communicate with each other.
 .
 ## More advanced usage for ROS2
 ### _Full support of ROS graph and topic lists via the forward discovery mode_
 By default the bridge doesn't route throught zenoh the DDS discovery traffic to
 the remote bridges.
 Meaning that, in case you use 2 **`zenoh-bridge-dds`** to interconnect 2 DDS
 domains, the DDS entities discovered in one domain won't be advertised in the
 other domain. Thus, the DDS data will be routed between the 2 domains only if
 matching readers and writers are declared in the 2 domains independently.
 .
 This default behaviour has an impact on ROS2 behaviour: on one side of the
 bridge the ROS graph might not reflect all the nodes from the other side of the
 bridge. The `ros2 topic list` command might not list all the topics declared on
 the other side. And the **ROS graph** is limited to the nodes in each domain.
 .
 But using the **`--fwd-discovery`** (or `-f`) option for all bridges make them
 behave differently:
  - each bridge will forward via zenoh the local DDS discovery data to the
 remote bridges (in a more compact way than the original DDS discovery traffic)
  - each bridge receiving DDS discovery data via zenoh will create a replica of
 the DDS reader or writer, with similar QoS. Those replicas will serve the route
 to/from zenoh, and will be discovered by the ROS2 nodes.
  - each bridge will forward the `ros_discovery_info` data (in a less intensive
 way than the original publications) to the remote bridges. On reception, the
 remote bridges will convert the original entities' GIDs into the GIDs of the
 corresponding replicas, and re-publish on DDS the `ros_discovery_info`. The
 full ROS graph can then be discovered by the ROS2 nodes on each host.
 ### _Limiting the ROS2 topics, services, parameters or actions to be routed_
 By default 2 zenoh bridges will route all ROS2 topics and services for which
 they detect a Writer on one side and a Reader on the other side. But you might
 want to avoid some topics and services to be routed by the bridge.
 .
 Starting `zenoh-bridge-dds` you can use the `--allow` argument to specify the
 subset of topics and services that will be routed by the bridge. This argument
 accepts a string wich is a regular expression that must match a substring of an
 allowed zenoh key (see details of [mapping of ROS2 names to zenoh
 keys](#mapping-ros2-names-to-zenoh-keys)).
 .
 Here are some examples of usage:
 | `--allow` value | allowed ROS2 communication |
 | :-- | :-- |
 | `/rosout` | `/rosout`|
 | `/rosout\|/turtle1/cmd_vel\|/turtle1/rotate_absolute` |
 `/rosout`<br>`/turtle1/cmd_vel`<br>`/turtle1/rotate_absolute` |
 | `/rosout\|/turtle1/` | `/rosout` and all `/turtle1` topics, services,
 parameters and actions |
 | `/turtle1/.*` | all topics and services with name containing `/turtle1/` |
 | `/turtle1/` | same: all topics, services, parameters and actions with name
 containing `/turtle1/` |
 | `rt/turtle1` | all topics with name containing `/turtle1` (no services,
 parameters or actions) |
 | `rq/turtle1\|/rr/turtle1` | all services and parameters with name containing
 `/turtle1` (no topics or actions) |
 | `rq/turtlesim/.*parameter\|/rr/turtlesim/.*parameter` | all parameters with
 name containing `/turtlesim` (no topics, services or actions) |
 | `rq/turtle1/.*/_action\|/rr/turtle1/.*/_action` | all actions with name
 containing `/turtle1` (no topics, services or parameters) |
 .
 ### _Running several robots without changing the ROS2 configuration_
 If you run similar robots in the same network, they will by default all us the
 same DDS topics, leading to interferences in their operations.
 A simple way to address this issue using the zenoh bridge is to:
  - deploy 1 zenoh bridge per robot
  - have each bridge started with the `--scope "/<id>"` argument, each robot
 having its own id.
  - make sure each robot cannot directly communicate via DDS with another robot
 by setting a distinct domain per robot, or configuring its network interface to
 not route UDP multicast outside the host.
 .
 Using the `--scope` option, a prefix is added to each zenoh key
 published/subscribed by the bridge (more details in [mapping of ROS2 names to
 zenoh keys](#mapping-ros2-names-to-zenoh-keys)). To interact with a robot, a
 remote ROS2 application must use a zenoh bridge configured with the same scope
 than the robot.
 .
 ### _Closer integration of ROS2 with zenoh_
 As you understood, using the zenoh bridge, each ROS2 publications and
 subscriptions are mapped to a zenoh key. Therefore, its relatively easy to
 develop an application using one of the [zenoh
 APIs](https://zenoh.io/docs/apis/apis/) to interact with one or more robot at
 the same time.
 .
 See in details how to achieve that in [this
 blog](https://zenoh.io/blog/2021-04-28-ros2-integration/).
 .
 ## Configuration
 .
 `zenoh-bridge-dds` can be configured via a JSON5 file passed via the
 `-c`argument. You can see a commented example of such configuration file:
 [`DEFAULT_CONFIG.json5`](DEFAULT_CONFIG.json5).
 .
 The `"dds"` part of this same configuration file can also be used in the
 configuration file for the zenoh router (within its `"plugins"` part). The
 router will automatically try to load the plugin library (`zenoh-plugin_dds`)
 at startup and apply its configuration.
 .
 `zenoh-bridge-dds` also accepts the following arguments. If set, each argument
 will override the similar setting from the configuration file:
  * zenoh-related arguments:
    - **`-c, --config <FILE>`** : a config file
    - **`-m, --mode <MODE>`** : The zenoh session mode. Default: `peer` Possible
 values: `peer` or `client`.
       See [zenoh
 documentation](https://zenoh.io/docs/getting-started/key-concepts/#deployment-units)
 for more details.
    - **`-l, --listen <LOCATOR>`** : A locator on which this router will listen
 for incoming sessions. Repeat this option to open several listeners. Example of
 locator: `tcp/localhost:7447`.
    - **`-e, --peer <LOCATOR>`** : A peer locator this router will try to
 connect to (typically another bridge or a zenoh router). Repeat this option to
 connect to several peers. Example of locator: `tcp/<ip-address>:7447`.
    - **`--no-multicast-scouting`** : disable the zenoh scouting protocol that
 allows automatic discovery of zenoh peers and routers.
    - **`-i, --id <hex_string>`** : The identifier (as an hexadecimal string -
 e.g.: 0A0B23...) that the zenoh bridge must use. **WARNING: this identifier
 must be unique in the system!** If not set, a random UUIDv4 will be used.
    - **`--group-member-id <ID>`** : The bridges are supervising each other via
 zenoh liveliness tokens. This option allows to set a custom identifier for the
 bridge, that will be used the liveliness token key (if not specified, the zenoh
 UUID is used).
    - **`--rest-http-port <rest-http-port>`** : set the REST API http port
 (default: 8000)
  * DDS-related arguments:
    - **`-d, --domain <ID>`** : The DDS Domain ID. By default set to `0`, or to
 `"$ROS_DOMAIN_ID"` is this environment variable is defined.
    - **`--dds-localhost-only`** : If set, the DDS discovery and traffic will
 occur only on the localhost interface (127.0.0.1).
      By default set to false, unless the "ROS_LOCALHOST_ONLY=1" environment
 variable is defined.
    - **`-f, --fwd-discovery`** : When set, rather than creating a local route
 when discovering a local DDS entity, this discovery info is forwarded to the
 remote plugins/bridges. Those will create the routes, including a replica of
 the discovered entity. More details
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
    - **`-s, --scope <String>`** : A string used as prefix to scope DDS traffic
 when mapped to zenoh keys.
    - **`-a, --allow <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must be routed via zenoh.
      By default, all partitions and topics are allowed.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
      Examples of expressions:
         - `.*/TopicA` will allow only the `TopicA` to be routed, whatever the
 partition.
         - `PartitionX/.*` will allow all the topics to be routed, but only on
 `PartitionX`.
         - `cmd_vel|rosout` will allow only the topics containing `cmd_vel` or
 `rosout` in their name or partition name to be routed.
    - **`--deny <String>`** :  A regular expression matching the set of
 'partition/topic-name' that must NOT be routed via zenoh.
      By default, no partitions and no topics are denied.
      If both 'allow' and 'deny' are set a partition and/or topic will be
 allowed if it matches only the 'allow' expression.
      Repeat this option to configure several topic expressions. These
 expressions are concatenated with '|'.
    - **`--max-frequency <String>...`** : specifies a maximum frequency of data
 routing over zenoh per-topic. The string must have the format `"regex=float"`
 where:
        - `"regex"` is a regular expression matching the set of
 'partition/topic-name' for which the data (per DDS instance) must be routedat
 no higher rate than associated max frequency (same syntax than --allow option).
        - `"float"` is the maximum frequency in Hertz; if publication rate is
 higher, downsampling will occur when routing.
 .
        (usable multiple times)
    - **`--queries-timeout <Duration>`**: A duration in seconds (default: 5.0
 sec) that will be used as a timeout when the bridge
      queries any other remote bridge for discovery information and for
 historical data for TRANSIENT_LOCAL DDS Readers it serves
      (i.e. if the query to the remote bridge exceed the timeout, some
 historical samples might be not routed to the Readers,
      but the route will not be blocked forever).
    - **`-w, --generalise-pub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh publications, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
    - **`-r, --generalise-sub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh subscriptions, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
 .
 ## Admin space
 .
 The zenoh bridge for DDS exposes an administration space allowing to browse the
 DDS entities that have been discovered (with their QoS), and the routes that
 have been established between DDS and zenoh.
 This administration space is accessible via any zenoh API, including the REST
 API that you can activate at `zenoh-bridge-dds` startup using the
 `--rest-http-port` argument.
 .
 The `zenoh-bridge-dds` exposes this administration space with paths prefixed by
 `@/service/<uuid>/dds` (where `<uuid>` is the unique identifier of the bridge
 instance). The informations are then organized with such paths:
  - `@/service/<uuid>/dds/version` : the bridge version
  - `@/service/<uuid>/dds/config` : the bridge configuration
  - `@/service/<uuid>/dds/participant/<gid>/reader/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/participant/<gid>/writer/<gid>/<topic>` : a discovered
 DDS reader on `<topic>`
  - `@/service/<uuid>/dds/route/from_dds/<zenoh-resource>` : a route established
 from a DDS writer to a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources)).
  - `@/service/<uuid>/dds/route/to_dds/<zenoh-resource>` : a route established
 from a zenoh key named `<zenoh-resource>` (see [mapping
 rules](#mapping-dds-topics-to-zenoh-resources))..
 .
 Example of queries on administration space using the REST API with the `curl`
 command line tool (don't forget to activate the REST API with `--rest-http-port
 8000` argument):
  - List all the DDS entities that have been discovered:
     ```bash
     curl http://localhost:8000/@/service/**/participant/**
     ```
  - List all established routes:
     ```bash
     curl http://localhost:8000/@/service/**/route/**
     ```
  - List all discovered DDS entities and established route for topic `cmd_vel`:
     ```bash
     curl http://localhost:8000/@/service/**/cmd_vel
     ```
 .
 > _Pro tip: pipe the result into [**jq**](https://stedolan.github.io/jq/)
 command for JSON pretty print or transformation._
 .
 ## Architecture details
 .
 Whether it's built as a library or as a standalone executable, the **zenoh
 bridge for DDS** do the same things:
 - in default mode:
   - it discovers the DDS readers and writers declared by any DDS application,
 via the standard DDS discovery protocol (that uses UDP multicast)
   - it creates a mirror DDS writer or reader for each discovered reader or
 writer (using the same QoS)
   - if maps the discovered DDS topics and partitions to zenoh keys (see mapping
 details below)
   - it forwards user's data from a DDS topic to the corresponding zenoh key,
 and vice versa
   - it does not forward to the remote bridge any DDS discovery information
 .
 - in "forward discovery" mode
   - it behaves as described
 [here](#full-support-of-ros-graph-and-topic-lists-via-the-forward-discovery-mode)
 ### _Mapping of DDS topics to zenoh keys_
 The mapping between DDS and zenoh is rather straightforward: given a DDS
 Reader/Writer for topic **`A`** without the partition QoS set, then the
 equivalent zenoh key will have the same name: **`A`**.
 If a partition QoS **`P`** is defined, the equivalent zenoh key will be named
 as **`P/A`**.
 .
 Optionally, the bridge can be configured with a **scope** that will be used as
 a prefix to each zenoh key.
 That is, for scope **`S`** the equivalent zenoh key will be:
  - **`S/A`** for a topic **`A`** without partition
  - **`S/P/A`** for a topic **`A`** and a partition **`P`**
 .
 ### _Mapping ROS2 names to zenoh keys_
 The mapping from ROS2 topics and services name to DDS topics is specified
 [here](https://design.ros2.org/articles/topic_and_service_names.html#mapping-of-ros-2-topic-and-service-names-to-dds-concepts).
 Notice that ROS2 does not use the DDS partitions.
 As a consequence of this mapping and of the DDS to zenoh mapping specified
 above, here are some examples of mapping from ROS2 names to zenoh keys:
 .
 | ROS2 names | DDS Topics names | zenoh keys (no scope) | zenoh keys (if
 scope="`myscope`") |
 | --- | --- | --- | --- |
 | topic: `/rosout` | `rt/rosout` | `rt/rosout` | `myscope/rt/rosout` |
 | topic: `/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` | `rt/turtle1/cmd_vel` |
 `myscope/rt/turtle1/cmd_vel` |
 | service: `/turtle1/set_pen` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `rq/turtle1/set_penRequest`<br>`rr/turtle1/set_penReply` |
 `myscope/rq/turtle1/set_penRequest`<br>`myscope/rr/turtle1/set_penReply` |
 | action: `/turtle1/rotate_absolute` |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`rt/turtle1/rotate_absolute/_action/status`<br>`rt/turtle1/rotate_absolute/_action/feedback`
 |
 `myscope/rq/turtle1/rotate_absolute/_action/send_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/send_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/cancel_goalRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/cancel_goalReply`<br>`myscope/rq/turtle1/rotate_absolute/_action/get_resultRequest`<br>`myscope/rr/turtle1/rotate_absolute/_action/get_resultReply`<br>`myscope/rt/turtle1/rotate_absolute/_action/status`<br>`myscope/rt/turtle1/rotate_absolute/_action/feedback`
 |
 | all parameters for node `turtlesim`|
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `rq/turtlesim/list_parametersRequest`<br>`rr/turtlesim/list_parametersReply`<br>`rq/turtlesim/describe_parametersRequest`<br>`rr/turtlesim/describe_parametersReply`<br>`rq/turtlesim/get_parametersRequest`<br>`rr/turtlesim/get_parametersReply`<br>`rr/turtlesim/get_parameter_typesReply`<br>`rq/turtlesim/get_parameter_typesRequest`<br>`rq/turtlesim/set_parametersRequest`<br>`rr/turtlesim/set_parametersReply`<br>`rq/turtlesim/set_parameters_atomicallyRequest`<br>`rr/turtlesim/set_parameters_atomicallyReply`
 |
 `myscope/rq/turtlesim/list_parametersRequest`<br>`myscope/rr/turtlesim/list_parametersReply`<br>`myscope/rq/turtlesim/describe_parametersRequest`<br>`myscope/rr/turtlesim/describe_parametersReply`<br>`myscope/rq/turtlesim/get_parametersRequest`<br>`myscope/rr/turtlesim/get_parametersReply`<br>`myscope/rr/turtlesim/get_parameter_typesReply`<br>`myscope/rq/turtlesim/get_parameter_typesRequest`<br>`myscope/rq/turtlesim/set_parametersRequest`<br>`myscope/rr/turtlesim/set_parametersReply`<br>`myscope/rq/turtlesim/set_parameters_atomicallyRequest`<br>`myscope/rr/turtlesim/set_parameters_atomicallyReply`
 |
 | specific ROS discovery topic | `ros_discovery_info` | `ros_discovery_info` |
 `myscope/ros_discovery_info`
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-dds
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-dds

Package: zenoh-plugin-mqtt
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2882
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-mqtt_0.7.2-rc_arm64.deb
Size: 814064
MD5sum: 6887d5c74c844193c6e13ef9b7e2271d
SHA1: 6681bab873e1c9bfef3e11254627707875b8959c
SHA256: 4c7590d91d98f78f3eda5a01fc7e2ac46c73ec193ca3e1515d06535ed90daa83
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for MQTT
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-mqtt/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-mqtt/actions?query=workflow%3ARust)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # MQTT plugin and standalone `zenoh-bridge-mqtt`
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Docker image:** see [below](#Docker-image)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ## Background
 .
 [MQTT](https://mqtt.org/) is a pub/sub protocol leveraging a broker to route
 the messages between the MQTT clients.
 The MQTT plugin for Eclipse Zenoh acts as a MQTT broker, accepting connections
 from MQTT clients (V3 and V5) and translating the MQTT pub/sub into a Zenoh
 pub/sub.
 I.e.:
  - a MQTT publication on topic `device/123/temperature` is routed as a Zenoh
 publication on key expression `device/123/temperature`
  - a MQTT subscription on topic `device/#` is mapped to a Zenoh subscription on
 key expression `device/**`
 .
 This allows a close intergration of any MQTT system with Zenoh, but also brings
 to MQTT systems the benefits of a Zenoh routing infrastructure.
 Some examples of use cases:
  - Routing MQTT from the device to the Edge and to the Cloud
  - Bridging 2 distinct MQTT systems across the Internet, with NAT traversal
  - Pub/sub to MQTT via the Zenoh REST API
  - MQTT-ROS2 (robot) communication
  - Store MQTT publications in any Zenoh storage (RocksDB, InfluxDB, file
 system...)
  - MQTT record/replay with InfluxDB as a storage
 .
 The MQTT plugin for Eclipse Zenoh is available either as a dynamic library to
 be loaded by the Zenoh router (`zenohd`), either as a standalone executable
 (`zenoh-bridge-mqtt`) that can acts as a Zenoh client or peer.
 .
 ## Configuration
 .
 `zenoh-bridge-mqtt` can be configured via a JSON5 file passed via the
 `-c`argument. You can see a commented example of such configuration file:
 [`DEFAULT_CONFIG.json5`](DEFAULT_CONFIG.json5).
 .
 The `"mqtt"` part of this same configuration file can also be used in the
 configuration file for the zenoh router (within its `"plugins"` part). The
 router will automatically try to load the plugin library (`zenoh_plugin_mqtt`)
 at startup and apply its configuration.
 .
 `zenoh-bridge-mqtt` also accepts the following arguments. If set, each argument
 will override the similar setting from the configuration file:
  * zenoh-related arguments:
    - **`-c, --config <FILE>`** : a config file
    - **`-m, --mode <MODE>`** : The zenoh session mode. Default: `peer` Possible
 values: `peer` or `client`.
       See [zenoh
 documentation](https://zenoh.io/docs/getting-started/key-concepts/#deployment-units)
 for more details.
    - **`-l, --listen <LOCATOR>`** : A locator on which this router will listen
 for incoming sessions. Repeat this option to open several listeners. Example of
 locator: `tcp/localhost:7447`.
    - **`-e, --peer <LOCATOR>`** : A peer locator this router will try to
 connect to (typically another bridge or a zenoh router). Repeat this option to
 connect to several peers. Example of locator: `tcp/<ip-address>:7447`.
    - **`--no-multicast-scouting`** : disable the zenoh scouting protocol that
 allows automatic discovery of zenoh peers and routers.
    - **`-i, --id <hex_string>`** : The identifier (as an hexadecimal string -
 e.g.: 0A0B23...) that the zenoh bridge must use. **WARNING: this identifier
 must be unique in the system!** If not set, a random UUIDv4 will be used.
    - **`--rest-http-port [PORT | IP:PORT]`** : Configures HTTP interface for
 the REST API (disabled by default, setting this option enables it). Accepted
 values:
        - a port number
        - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface).
  * MQTT-related arguments:
    - **`-p, --port [PORT | IP:PORT]`** : The address to bind the MQTT server.
 Default: `"0.0.0.0:1883"`. Accepted values:
        - a port number (`"0.0.0.0"` will be used as IP to bind, meaning any
 interface of the host)
        - a string with format `<local_ip>:<port_number>` (to bind the MQTT
 server to a specific interface).
    - **`-s, --scope <String>`** : A string added as prefix to all routed MQTT
 topics when mapped to a zenoh key expression. This should be used to avoid
 conflicts when several distinct MQTT systems using the same topics names are
 routed via Zenoh.
    - **`-a, --allow <String>`** :  A regular expression matching the MQTT topic
 name that must be routed via zenoh. By default all topics are allowed. If both
 `--allow` and `--deny` are set a topic will be allowed if it matches only the
 'allow' expression.
    - **`--deny <String>`** :  A regular expression matching the MQTT topic name
 that must not be routed via zenoh. By default no topics are denied. If both
 `--allow` and `--deny` are set a topic will be allowed if it matches only the
 'allow' expression.
    - **`-w, --generalise-pub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh publications, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
    - **`-r, --generalise-sub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh subscriptions, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
 .
 ## Admin space
 .
 The zenoh bridge for MQTT exposes an administration space allowing to get some
 information on its status and configuration.
 This administration space is accessible via any zenoh API, including the REST
 API that you can activate at `zenoh-bridge-mqtt` startup using the
 `--rest-http-port` argument.
 .
 The `zenoh-bridge-mqtt` exposes this administration space with paths prefixed
 by `@/service/<uuid>/mqtt` (where `<uuid>` is the unique identifier of the
 bridge instance). The informations are then organized with such paths:
  - `@/service/<uuid>/mqtt/version` : the bridge version
  - `@/service/<uuid>/mqtt/config` : the bridge configuration
 .
 Example of queries on administration space using the REST API with the `curl`
 command line tool (don't forget to activate the REST API with `--rest-http-port
 8000` argument):
  - ```bash
    curl http://localhost:8000:/@/service/**
    ```
 .
 > _Pro tip: pipe the result into [**jq**](https://stedolan.github.io/jq/)
 command for JSON pretty print or transformation._
 .
 .
 ## How to install it
 .
 To install the latest release of either the MQTT plugin for the Zenoh router,
 either the `zenoh-bridge-mqtt` standalone executable, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-plugin-mqtt/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download:
  - the `zenoh-plugin-mqtt-<version>-<platform>.zip` file for the plugin.
    Then unzip it in the same directory than `zenohd` or to any directory where
 it can find the plugin library (e.g. /usr/lib)
  - the `zenoh-bridge-mqtt-<version>-<platform>.zip` file for the standalone
 executable.
    Then unzip it where you want, and run the extracted `zenoh-bridge-mqtt`
 binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 ```
 Then either:
   - install the plugin with: `sudo apt install zenoh-plugin-mqtt`.
   - install the standalone executable with: `sudo apt install
 zenoh-bridge-mqtt`.
 .
 .
 ## Docker image
 The **`zenoh-bridge-mqtt`** standalone executable is also available as a
 [Docker
 images](https://hub.docker.com/r/eclipse/zenoh-bridge-mqtt/tags?page=1&ordering=last_updated)
 for both amd64 and arm64. To get it, do:
   - `docker pull eclipse/zenoh-bridge-mqtt:latest` for the latest release
   - `docker pull eclipse/zenoh-bridge-mqtt:master` for the master branch
 version (nightly build)
 .
 Usage: **`docker run --init -p 1883:1883 eclipse/zenoh-bridge-mqtt`**
 It supports the same command line arguments than the `zenoh-bridge-mqtt` (see
 above or check with `-h` argument).
 .
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 In order to build the zenoh bridge for MQTT you only need to install
 [Rust](https://www.rust-lang.org/tools/install).
 .
 Then, you may clone the repository on your machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-mqtt.git
 $ cd zenoh-plugin-mqtt
 ```
 .
 You can then choose between building the zenoh bridge for MQTT:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-mqtt
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-mqtt
 ```
 The **`zenoh-bridge-mqtt`** binary will be generated in the `target/release`
 sub-directory.
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt

Package: zenoh-plugin-mqtt
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3282
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-mqtt_0.7.2-rc_amd64.deb
Size: 937148
MD5sum: e1f4b5a4f49060673edc7ed5f3ff9144
SHA1: 79807efd95870b9d04e5911b6722ff4db1e78967
SHA256: 4ed63f18c97768758271f01eab25ef713dffebd76d2f63ea1575c379bdf20142
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for MQTT
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-mqtt/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-mqtt/actions?query=workflow%3ARust)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # MQTT plugin and standalone `zenoh-bridge-mqtt`
 .
 :point_right: **Install latest release:** see [below](#How-to-install-it)
 .
 :point_right: **Docker image:** see [below](#Docker-image)
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 ## Background
 .
 [MQTT](https://mqtt.org/) is a pub/sub protocol leveraging a broker to route
 the messages between the MQTT clients.
 The MQTT plugin for Eclipse Zenoh acts as a MQTT broker, accepting connections
 from MQTT clients (V3 and V5) and translating the MQTT pub/sub into a Zenoh
 pub/sub.
 I.e.:
  - a MQTT publication on topic `device/123/temperature` is routed as a Zenoh
 publication on key expression `device/123/temperature`
  - a MQTT subscription on topic `device/#` is mapped to a Zenoh subscription on
 key expression `device/**`
 .
 This allows a close intergration of any MQTT system with Zenoh, but also brings
 to MQTT systems the benefits of a Zenoh routing infrastructure.
 Some examples of use cases:
  - Routing MQTT from the device to the Edge and to the Cloud
  - Bridging 2 distinct MQTT systems across the Internet, with NAT traversal
  - Pub/sub to MQTT via the Zenoh REST API
  - MQTT-ROS2 (robot) communication
  - Store MQTT publications in any Zenoh storage (RocksDB, InfluxDB, file
 system...)
  - MQTT record/replay with InfluxDB as a storage
 .
 The MQTT plugin for Eclipse Zenoh is available either as a dynamic library to
 be loaded by the Zenoh router (`zenohd`), either as a standalone executable
 (`zenoh-bridge-mqtt`) that can acts as a Zenoh client or peer.
 .
 ## Configuration
 .
 `zenoh-bridge-mqtt` can be configured via a JSON5 file passed via the
 `-c`argument. You can see a commented example of such configuration file:
 [`DEFAULT_CONFIG.json5`](DEFAULT_CONFIG.json5).
 .
 The `"mqtt"` part of this same configuration file can also be used in the
 configuration file for the zenoh router (within its `"plugins"` part). The
 router will automatically try to load the plugin library (`zenoh_plugin_mqtt`)
 at startup and apply its configuration.
 .
 `zenoh-bridge-mqtt` also accepts the following arguments. If set, each argument
 will override the similar setting from the configuration file:
  * zenoh-related arguments:
    - **`-c, --config <FILE>`** : a config file
    - **`-m, --mode <MODE>`** : The zenoh session mode. Default: `peer` Possible
 values: `peer` or `client`.
       See [zenoh
 documentation](https://zenoh.io/docs/getting-started/key-concepts/#deployment-units)
 for more details.
    - **`-l, --listen <LOCATOR>`** : A locator on which this router will listen
 for incoming sessions. Repeat this option to open several listeners. Example of
 locator: `tcp/localhost:7447`.
    - **`-e, --peer <LOCATOR>`** : A peer locator this router will try to
 connect to (typically another bridge or a zenoh router). Repeat this option to
 connect to several peers. Example of locator: `tcp/<ip-address>:7447`.
    - **`--no-multicast-scouting`** : disable the zenoh scouting protocol that
 allows automatic discovery of zenoh peers and routers.
    - **`-i, --id <hex_string>`** : The identifier (as an hexadecimal string -
 e.g.: 0A0B23...) that the zenoh bridge must use. **WARNING: this identifier
 must be unique in the system!** If not set, a random UUIDv4 will be used.
    - **`--rest-http-port [PORT | IP:PORT]`** : Configures HTTP interface for
 the REST API (disabled by default, setting this option enables it). Accepted
 values:
        - a port number
        - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface).
  * MQTT-related arguments:
    - **`-p, --port [PORT | IP:PORT]`** : The address to bind the MQTT server.
 Default: `"0.0.0.0:1883"`. Accepted values:
        - a port number (`"0.0.0.0"` will be used as IP to bind, meaning any
 interface of the host)
        - a string with format `<local_ip>:<port_number>` (to bind the MQTT
 server to a specific interface).
    - **`-s, --scope <String>`** : A string added as prefix to all routed MQTT
 topics when mapped to a zenoh key expression. This should be used to avoid
 conflicts when several distinct MQTT systems using the same topics names are
 routed via Zenoh.
    - **`-a, --allow <String>`** :  A regular expression matching the MQTT topic
 name that must be routed via zenoh. By default all topics are allowed. If both
 `--allow` and `--deny` are set a topic will be allowed if it matches only the
 'allow' expression.
    - **`--deny <String>`** :  A regular expression matching the MQTT topic name
 that must not be routed via zenoh. By default no topics are denied. If both
 `--allow` and `--deny` are set a topic will be allowed if it matches only the
 'allow' expression.
    - **`-w, --generalise-pub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh publications, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
    - **`-r, --generalise-sub <String>`** :  A list of key expressions to use
 for generalising the declaration of
      the zenoh subscriptions, and thus minimizing the discovery traffic (usable
 multiple times).
      See [this
 blog](https://zenoh.io/blog/2021-03-23-discovery/#leveraging-resource-generalisation)
 for more details.
 .
 ## Admin space
 .
 The zenoh bridge for MQTT exposes an administration space allowing to get some
 information on its status and configuration.
 This administration space is accessible via any zenoh API, including the REST
 API that you can activate at `zenoh-bridge-mqtt` startup using the
 `--rest-http-port` argument.
 .
 The `zenoh-bridge-mqtt` exposes this administration space with paths prefixed
 by `@/service/<uuid>/mqtt` (where `<uuid>` is the unique identifier of the
 bridge instance). The informations are then organized with such paths:
  - `@/service/<uuid>/mqtt/version` : the bridge version
  - `@/service/<uuid>/mqtt/config` : the bridge configuration
 .
 Example of queries on administration space using the REST API with the `curl`
 command line tool (don't forget to activate the REST API with `--rest-http-port
 8000` argument):
  - ```bash
    curl http://localhost:8000:/@/service/**
    ```
 .
 > _Pro tip: pipe the result into [**jq**](https://stedolan.github.io/jq/)
 command for JSON pretty print or transformation._
 .
 .
 ## How to install it
 .
 To install the latest release of either the MQTT plugin for the Zenoh router,
 either the `zenoh-bridge-mqtt` standalone executable, you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh-plugin-mqtt/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download:
  - the `zenoh-plugin-mqtt-<version>-<platform>.zip` file for the plugin.
    Then unzip it in the same directory than `zenohd` or to any directory where
 it can find the plugin library (e.g. /usr/lib)
  - the `zenoh-bridge-mqtt-<version>-<platform>.zip` file for the standalone
 executable.
    Then unzip it where you want, and run the extracted `zenoh-bridge-mqtt`
 binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list > /dev/null
 sudo apt update
 ```
 Then either:
   - install the plugin with: `sudo apt install zenoh-plugin-mqtt`.
   - install the standalone executable with: `sudo apt install
 zenoh-bridge-mqtt`.
 .
 .
 ## Docker image
 The **`zenoh-bridge-mqtt`** standalone executable is also available as a
 [Docker
 images](https://hub.docker.com/r/eclipse/zenoh-bridge-mqtt/tags?page=1&ordering=last_updated)
 for both amd64 and arm64. To get it, do:
   - `docker pull eclipse/zenoh-bridge-mqtt:latest` for the latest release
   - `docker pull eclipse/zenoh-bridge-mqtt:master` for the master branch
 version (nightly build)
 .
 Usage: **`docker run --init -p 1883:1883 eclipse/zenoh-bridge-mqtt`**
 It supports the same command line arguments than the `zenoh-bridge-mqtt` (see
 above or check with `-h` argument).
 .
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 In order to build the zenoh bridge for MQTT you only need to install
 [Rust](https://www.rust-lang.org/tools/install).
 .
 Then, you may clone the repository on your machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-mqtt.git
 $ cd zenoh-plugin-mqtt
 ```
 .
 You can then choose between building the zenoh bridge for MQTT:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-mqtt
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-mqtt
 ```
 The **`zenoh-bridge-mqtt`** binary will be generated in the `target/release`
 sub-directory.
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-mqtt

Package: zenoh-plugin-rest
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2747
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-rest_0.7.2-rc_armhf.deb
Size: 832668
MD5sum: a4047b2aec4ee4a081de9a1ba8043a51
SHA1: ab09a8571eda201a5f86c302414df47488da5f1e
SHA256: 778b11d6e95bf397ebaa2fb96d2aa0c891b91f1602934323138e574e7f5f81a8
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh REST plugin
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-rest
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3260
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-rest_0.7.2-rc_amd64.deb
Size: 950368
MD5sum: 09f10056b438ba0bc824cd24cff4ea25
SHA1: ca09660c4ea4b3503da2c82cc1610268cdc0e350
SHA256: 2a7ee0f9059c8f317e73087dbc4a6d4d7482caa8208c7ad6be68fa1a8ed49fab
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh REST plugin
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-rest
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2880
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-rest_0.7.2-rc_arm64.deb
Size: 834612
MD5sum: 8290c0a506014b6d3961ce300c41891c
SHA1: 34264e88137c197a991b020225354af3cda61860
SHA256: 1bd77ae53a347361e657e26c50220f903f2d9f64a16fbf8d88afd83cbc2d0544
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh REST plugin
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-rest
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2803
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-rest_0.7.2-rc_armel.deb
Size: 841852
MD5sum: dcb0ed6711d73612b5fad93bc52c722a
SHA1: c317c43988607f5a81231053c20c9af1b6d4fb14
SHA256: b99836e22ec917e1302697059cbc4e7ad6b64507850198f5fcc69c1c11ea6851
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh REST plugin
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-ros1
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 5582
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-ros1_0.7.2-rc_amd64.deb
Size: 1681732
MD5sum: db8771e0c9040147700fa8ef4a91c2c9
SHA1: 74a3968db2bd8f17ce38b27ba1a6bc620a9e1770
SHA256: 7cdd80d6249d0128b11761904c1ee8f0983e64b4ed28d35e3cb1f3d6ecd4c826
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh plugin for bidging ROS1
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 <!---
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-ros1/workflows/Rust/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-ros1/actions?query=workflow%3ARust)
 --->
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # ROS1 to Zenoh Bridge plugin
 .
 ## Background
 ROS1 is a well-known mature platform for building robotic systems. Despite the
 fact that next generation of ROS - ROS2 is released long time ago, many
 developers still prefer using ROS1. In order to integrate ROS1 systems to Zenoh
 infrastructure, [as it was done for
 DDS/ROS2](https://github.com/eclipse-zenoh/zenoh-plugin-dds), ROS1 to Zenoh
 Bridge was designed.
 .
 ## How to install it
 Currently, only out-of-source build is supported.
 .
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 > :warning: **WARNING** :warning: : We failed to build the plugin's tests on
 the system with 2(1)GB of RAM(swap) as ld ran out of memory, please pay
 attention to this fact!
 .
 In order to build the ROS1 to Zenoh Bridge, you need first to install the
 following dependencies:
 .
 - [Rust](https://www.rust-lang.org/tools/install)
 - On Linux, make sure the `llvm` and `clang` development packages are
 installed:
    - on Debians do: `sudo apt install llvm-dev libclang-dev`
    - on CentOS or RHEL do: `sudo yum install llvm-devel clang-devel`
    - on Alpine do: `apk install llvm11-dev clang-dev`
 .
 Once these dependencies are in place, you may clone the repository on your
 machine:
 .
 ```bash
 $ git clone https://github.com/eclipse-zenoh/zenoh-plugin-ros1.git
 $ cd zenoh-plugin-ros1
 ```
 .
 > :warning: **WARNING** :warning: : On Linux, don't use `cargo build` command
 without specifying a package with `-p`. Building both `zenoh-plugin-ros1`
 (plugin library) and `zenoh-bridge-ros1` (standalone executable) together will
 lead to a `multiple definition of `load_plugin'` error at link time. See
 [#117](https://github.com/eclipse-zenoh/zenoh-plugin-dds/issues/117#issuecomment-1439694331)
 for explanations.
 .
 You can then choose between building the zenoh bridge for ROS1:
 - as a plugin library that can be dynamically loaded by the zenoh router
 (`zenohd`):
 ```bash
 $ cargo build --release -p zenoh-plugin-ros1
 ```
 The plugin shared library (`*.so` on Linux, `*.dylib` on Mac OS, `*.dll` on
 Windows) will be generated in the `target/release` subdirectory.
 .
 - or as a standalone executable binary:
 ```bash
 $ cargo build --release -p zenoh-bridge-ros1
 ```
 The **`zenoh-bridge-ros1`** binary will be generated in the `target/release`
 sub-directory.
 .
 .
 ## A quick test with built-in examples
 .
 If you want to run examples or tests, you need to install ROS1:
 ```bash
 $ sudo apt install -y ros-base
 ```
 .
 There is a set of example utilities illustarating bridge in operation.
 Here is a description on how to configure the following schema:
 ```
 _____________________________
 ________________________________
 |                           |                               |
            |
 |        rosmaster_1        |                               |
 rosmaster_2          |
 |                           |                               |
            |
 | ros1_publisher -> ros_to_zenoh_bridge -> zenoh -> ros_to_zenoh_bridge ->
 ros1_subscriber |
 |___________________________|
 |______________________________|
 ```
 .
 1. Build everything:
 ```bash
 $ cargo build --release -p zenoh-bridge-ros1
 $ cargo test --release --no-run
 ```
 There are three executables we'll need:
 ```
 target/release/zenoh-bridge-ros1             // bridge executable
 target/release/examples/ros1_standalone_sub  // ros1 test subscriber
 target/release/examples/ros1_standalone_pub  // ros1 test publisher
 ```
 .
 2. Start first bridge together with rosmaster_1:
 ```bash
 $ ./target/release/zenoh-bridge-ros1 --with_rosmaster true --ros_master_uri
 http://localhost:10000
 ```
 At this step we start ROS1 master together with bridge isolated on port 10000
 .
 3. Start second bridge together with rosmaster_2:
 ```bash
 $ ./target/release/zenoh-bridge-ros1 --with_rosmaster true --ros_master_uri
 http://localhost:10001
 ```
 At this step we start ROS1 master together with bridge isolated on port 10001
 .
 4. Start ros1_subscriber:
 ```bash
 $ ROS_MASTER_URI=http://localhost:10000
 ./target/release/examples/ros1_standalone_sub
 ```
 The subscriber will work with ROS1 isolated on port 10000
 .
 5. Start ros1_publisher:
 ```bash
 $ ROS_MASTER_URI=http://localhost:10001
 ./target/release/examples/ros1_standalone_pub
 ```
 The publisher will work with ROS1 isolated on port 10001
 .
 Once completed, you will see the following exchange between ROS1 publisher and
 subscriber:
 <img src="pubsub.png">
 .
 .
 .
 ## Implementation
 Currently, ROS1 to Zenoh Bridge is based on [rosrust library
 fork](https://github.com/ZettaScaleLabs/rosrust). Some limitations are applied
 due to rosrust's implementation details, and we are targeting to re-engineer
 rosrust to overcome this
 .
 ## Limitations
 - all topic names are bridged as-is
 - all topic datatypes and md5 sums are bridged as "*" wildcard and may not work
 with some ROS1 client implementations
 - there is a performance impact coming from rosrust
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-ros1
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-ros1

Package: zenoh-plugin-storage-manager
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3288
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-storage-manager_0.7.2-rc_amd64.deb
Size: 951516
MD5sum: 39bebb4d0b8b3afa25a60d86d79fc021
SHA1: def3d958f9d8a4325e748591baf9b5768b532840
SHA256: b6b5c21c9fefac61a3bcd421bff29a59a174cb9c357397f3bdda73fb0bd4706e
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh storages plugin.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-storage-manager
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2872
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-storage-manager_0.7.2-rc_arm64.deb
Size: 826388
MD5sum: 0e2583b6dedb6cdbc2e217a9bff7a630
SHA1: e39350d06bdc19d7d586f726310a95ce20d90a8f
SHA256: 39f615eef8f2f68f739fa79ace3888cbe6446f28e5f9b1f1b760fad6bde28316
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh storages plugin.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-storage-manager
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2755
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-storage-manager_0.7.2-rc_armhf.deb
Size: 835852
MD5sum: fc52e673f814418e52befe6b89d55a37
SHA1: 9aa97c3c118265d5750fc0c6e273618dd7e5aa94
SHA256: f3e552bbcde470d8ec22a1e3f87dc3557141453d595a40fc6496273152999ccb
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh storages plugin.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-storage-manager
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 2819
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-storage-manager_0.7.2-rc_armel.deb
Size: 848140
MD5sum: b25c77d624ae1ab9d985b9ca3a095f75
SHA1: 1cf73af80f346f38c573e8d130c7c00549027004
SHA256: 0abf42cf9ff985e98dad7dee1572b1845d57126b53385b97f5334ff1d9b011ed
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: The zenoh storages plugin.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenoh-plugin-webserver
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 4311
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-webserver_0.7.2-rc_amd64.deb
Size: 1201584
MD5sum: 1ac64b9edc6dad13f93f1f8bd9a0eace
SHA1: 22024caaf9598b860a4213d76970bef31cb2ec69
SHA256: 0b4385719931f3a0ce20be67eb39a3e908c663db668f6fd1b270b8b466af7b41
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Plugin for Zenoh implementing an HTTP server that maps URLs to zenoh key
 expressions
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # Web Server plugin
 .
 The Web Server plugin implements an HTTP server mapping URLs to zenoh keys.
 This plugin can be used to set-up a Web server where the resources are
 retrieved from geo-distributed
 zenoh storages, each leveraging various backends (file system, database,
 memory...).
 .
 **Library name** `zenoh_plugin_webserver`
 .
 :point_right: **Download stable versions:**
 https://download.eclipse.org/zenoh/zenoh-plugin-webserver/
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Assuming you have a static website, you can:
  - expose the files as zenoh key/values using the [File System
 backend](https://github.com/eclipse-zenoh/zenoh-backend-filesystem)
  - set-up this Web Server plugin that will allow HTTP clients to browse the
 files.
 .
 Here are the steps:
  1. Make sure the libraries for the File System backend and the Web Server
 plugin are available for the zenoh router:
     either installing their packages (depending your platform), either
 downloading the library files corresponding
     to your platform in your `~/.zenoh/lib` directory.
  2. Copy the website files into a `~/.zenoh/zbackend_fs/my-site` directory (or
 make it a symbolic link to the path of your website)
  3. Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         webserver: {
           http_port: 8080,
         },
         storage_manager: {
           volumes: {
             fs: {}
           },
           storages: {
             demo: {
               key_expr: "my-site/**",
               strip_prefix: "my-site",
               volume: {
                 id: "fs",
                 dir: "my-site",
                 read_only: true
               }
             }
           }
         }
       }
     }
     ```
  4. Start the zenoh router (`zenohd`). It will automatically load the Web
 Server plugin and make it available on port 8080. It will also create a storage
 replying to any zenoh query on key expressions starting with `my-site/`.
  Now you can browse your site on http://localhost:8080/my-site.
 .
 .
 For more advanced use cases you can also:
  - Have the files of your web sites stored on different hosts. Running a zenoh
 router with a File System Storage on
    each host allow to make all the files available under the `my-site/` zenoh
 key.
  - Duplicate the files of your web sites on several hosts to provide fault
 tolerance.
  - Start several zenoh routers with the Web Service plugin on different hosts
 (not necessarly the same than the
    hosts running the File System storages). Each host will serve your web site.
  - Use other backends than the File System to store your resources and make
 them available through zenoh.
    (List of available backends
 [here](http://zenoh.io/docs/manual/backends-list/)).
  - Deploy a zenoh application that will implement `eval` function for a
 resource, replying to requests with a
    dynamic content (see the `z_eval` example in
    [Rust](https://github.com/eclipse-zenoh/zenoh/blob/master/zenoh/examples/zenoh/z_eval.rs)
 or
    [Python](https://github.com/eclipse-zenoh/zenoh-python/blob/master/examples/zenoh/z_eval.py)).
 .
 -------------------------------
 ## **Configuration**
 .
 In its configuration part, the plugin supports those settings:
  - **`http_port`** - int or string - required:
    either a port number as an integer or a string, either a string with format
 `"<local_ip>:<port_number>"`
 .
 -------------------------------
 ## **Troubleshooting**
 .
 ### *Address already in use*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T14:20:51Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 48, kind: AddrInUse, message: "Address already in use" }
 ```
 It means another process is already using this port number that the webserver
 plugin would like to use.
 In such case, you have 2 solutions:
  - stop the other process using this port
  - make the webserver plugin to another port changing its `listener` option.
 .
 ### *Permission denied*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T13:55:10Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 13, kind: PermissionDenied, message: "Permission denied"
 ```
 It probably means your OS (this usually happens on Linux) forbids the usage of
 the configured port for non-root user (actually it usually restricts all ports
 between 0 and 1024).
 In such case, you have 2 solutions:
  - run zenohd with root privileges (via `sudo`)
  - use another changing he webserver plugin's `listener` option.
 .
 -------------------------------
 ## **How to build it**
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release -p zenoh-plugin-webserver
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-webserver
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-webserver

Package: zenoh-plugin-webserver
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3586
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-webserver_0.7.2-rc_armhf.deb
Size: 1011780
MD5sum: c60f547015c3f0d740d757dc28451dda
SHA1: a2aff6f4727a439886585e7a2cb02e67b06380c1
SHA256: 26bf91b0cd099b5972241a71739e0d4c345dae11611e28ad90a430e7a328e659
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Plugin for Zenoh implementing an HTTP server that maps URLs to zenoh key
 expressions
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # Web Server plugin
 .
 The Web Server plugin implements an HTTP server mapping URLs to zenoh keys.
 This plugin can be used to set-up a Web server where the resources are
 retrieved from geo-distributed
 zenoh storages, each leveraging various backends (file system, database,
 memory...).
 .
 **Library name** `zenoh_plugin_webserver`
 .
 :point_right: **Download stable versions:**
 https://download.eclipse.org/zenoh/zenoh-plugin-webserver/
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Assuming you have a static website, you can:
  - expose the files as zenoh key/values using the [File System
 backend](https://github.com/eclipse-zenoh/zenoh-backend-filesystem)
  - set-up this Web Server plugin that will allow HTTP clients to browse the
 files.
 .
 Here are the steps:
  1. Make sure the libraries for the File System backend and the Web Server
 plugin are available for the zenoh router:
     either installing their packages (depending your platform), either
 downloading the library files corresponding
     to your platform in your `~/.zenoh/lib` directory.
  2. Copy the website files into a `~/.zenoh/zbackend_fs/my-site` directory (or
 make it a symbolic link to the path of your website)
  3. Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         webserver: {
           http_port: 8080,
         },
         storage_manager: {
           volumes: {
             fs: {}
           },
           storages: {
             demo: {
               key_expr: "my-site/**",
               strip_prefix: "my-site",
               volume: {
                 id: "fs",
                 dir: "my-site",
                 read_only: true
               }
             }
           }
         }
       }
     }
     ```
  4. Start the zenoh router (`zenohd`). It will automatically load the Web
 Server plugin and make it available on port 8080. It will also create a storage
 replying to any zenoh query on key expressions starting with `my-site/`.
  Now you can browse your site on http://localhost:8080/my-site.
 .
 .
 For more advanced use cases you can also:
  - Have the files of your web sites stored on different hosts. Running a zenoh
 router with a File System Storage on
    each host allow to make all the files available under the `my-site/` zenoh
 key.
  - Duplicate the files of your web sites on several hosts to provide fault
 tolerance.
  - Start several zenoh routers with the Web Service plugin on different hosts
 (not necessarly the same than the
    hosts running the File System storages). Each host will serve your web site.
  - Use other backends than the File System to store your resources and make
 them available through zenoh.
    (List of available backends
 [here](http://zenoh.io/docs/manual/backends-list/)).
  - Deploy a zenoh application that will implement `eval` function for a
 resource, replying to requests with a
    dynamic content (see the `z_eval` example in
    [Rust](https://github.com/eclipse-zenoh/zenoh/blob/master/zenoh/examples/zenoh/z_eval.rs)
 or
    [Python](https://github.com/eclipse-zenoh/zenoh-python/blob/master/examples/zenoh/z_eval.py)).
 .
 -------------------------------
 ## **Configuration**
 .
 In its configuration part, the plugin supports those settings:
  - **`http_port`** - int or string - required:
    either a port number as an integer or a string, either a string with format
 `"<local_ip>:<port_number>"`
 .
 -------------------------------
 ## **Troubleshooting**
 .
 ### *Address already in use*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T14:20:51Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 48, kind: AddrInUse, message: "Address already in use" }
 ```
 It means another process is already using this port number that the webserver
 plugin would like to use.
 In such case, you have 2 solutions:
  - stop the other process using this port
  - make the webserver plugin to another port changing its `listener` option.
 .
 ### *Permission denied*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T13:55:10Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 13, kind: PermissionDenied, message: "Permission denied"
 ```
 It probably means your OS (this usually happens on Linux) forbids the usage of
 the configured port for non-root user (actually it usually restricts all ports
 between 0 and 1024).
 In such case, you have 2 solutions:
  - run zenohd with root privileges (via `sudo`)
  - use another changing he webserver plugin's `listener` option.
 .
 -------------------------------
 ## **How to build it**
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release -p zenoh-plugin-webserver
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-webserver
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-webserver

Package: zenoh-plugin-webserver
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 4007
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-webserver_0.7.2-rc_arm64.deb
Size: 1072876
MD5sum: 18aa16a17db51e7d644f8f545089a470
SHA1: 23d16764536f04254b32ca00a63d5a7ca414020c
SHA256: 62acfee0e769986a6edb746a08f67b54c008c6377b2001e683d5238a2112e5e7
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Plugin for Zenoh implementing an HTTP server that maps URLs to zenoh key
 expressions
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # Web Server plugin
 .
 The Web Server plugin implements an HTTP server mapping URLs to zenoh keys.
 This plugin can be used to set-up a Web server where the resources are
 retrieved from geo-distributed
 zenoh storages, each leveraging various backends (file system, database,
 memory...).
 .
 **Library name** `zenoh_plugin_webserver`
 .
 :point_right: **Download stable versions:**
 https://download.eclipse.org/zenoh/zenoh-plugin-webserver/
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Assuming you have a static website, you can:
  - expose the files as zenoh key/values using the [File System
 backend](https://github.com/eclipse-zenoh/zenoh-backend-filesystem)
  - set-up this Web Server plugin that will allow HTTP clients to browse the
 files.
 .
 Here are the steps:
  1. Make sure the libraries for the File System backend and the Web Server
 plugin are available for the zenoh router:
     either installing their packages (depending your platform), either
 downloading the library files corresponding
     to your platform in your `~/.zenoh/lib` directory.
  2. Copy the website files into a `~/.zenoh/zbackend_fs/my-site` directory (or
 make it a symbolic link to the path of your website)
  3. Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         webserver: {
           http_port: 8080,
         },
         storage_manager: {
           volumes: {
             fs: {}
           },
           storages: {
             demo: {
               key_expr: "my-site/**",
               strip_prefix: "my-site",
               volume: {
                 id: "fs",
                 dir: "my-site",
                 read_only: true
               }
             }
           }
         }
       }
     }
     ```
  4. Start the zenoh router (`zenohd`). It will automatically load the Web
 Server plugin and make it available on port 8080. It will also create a storage
 replying to any zenoh query on key expressions starting with `my-site/`.
  Now you can browse your site on http://localhost:8080/my-site.
 .
 .
 For more advanced use cases you can also:
  - Have the files of your web sites stored on different hosts. Running a zenoh
 router with a File System Storage on
    each host allow to make all the files available under the `my-site/` zenoh
 key.
  - Duplicate the files of your web sites on several hosts to provide fault
 tolerance.
  - Start several zenoh routers with the Web Service plugin on different hosts
 (not necessarly the same than the
    hosts running the File System storages). Each host will serve your web site.
  - Use other backends than the File System to store your resources and make
 them available through zenoh.
    (List of available backends
 [here](http://zenoh.io/docs/manual/backends-list/)).
  - Deploy a zenoh application that will implement `eval` function for a
 resource, replying to requests with a
    dynamic content (see the `z_eval` example in
    [Rust](https://github.com/eclipse-zenoh/zenoh/blob/master/zenoh/examples/zenoh/z_eval.rs)
 or
    [Python](https://github.com/eclipse-zenoh/zenoh-python/blob/master/examples/zenoh/z_eval.py)).
 .
 -------------------------------
 ## **Configuration**
 .
 In its configuration part, the plugin supports those settings:
  - **`http_port`** - int or string - required:
    either a port number as an integer or a string, either a string with format
 `"<local_ip>:<port_number>"`
 .
 -------------------------------
 ## **Troubleshooting**
 .
 ### *Address already in use*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T14:20:51Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 48, kind: AddrInUse, message: "Address already in use" }
 ```
 It means another process is already using this port number that the webserver
 plugin would like to use.
 In such case, you have 2 solutions:
  - stop the other process using this port
  - make the webserver plugin to another port changing its `listener` option.
 .
 ### *Permission denied*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T13:55:10Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 13, kind: PermissionDenied, message: "Permission denied"
 ```
 It probably means your OS (this usually happens on Linux) forbids the usage of
 the configured port for non-root user (actually it usually restricts all ports
 between 0 and 1024).
 In such case, you have 2 solutions:
  - run zenohd with root privileges (via `sudo`)
  - use another changing he webserver plugin's `listener` option.
 .
 -------------------------------
 ## **How to build it**
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release -p zenoh-plugin-webserver
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-webserver
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-webserver

Package: zenoh-plugin-webserver
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 3682
Depends: zenohd (=0.7.2-rc)
Filename: 0.7.2-rc/zenoh-plugin-webserver_0.7.2-rc_armel.deb
Size: 1022668
MD5sum: 54d8682acd725900f3597c439025bc73
SHA1: 5e9f50fa8bb521b67e8fcc024fd3ee1fb79e9d6e
SHA256: 1c5485a0c92e3b62ffc457ca9924bdce92ff44fb44ab474bc504ab14980fcc18
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Plugin for Zenoh implementing an HTTP server that maps URLs to zenoh key
 expressions
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/actions?query=workflow%3A%22CI%22)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 # Web Server plugin
 .
 The Web Server plugin implements an HTTP server mapping URLs to zenoh keys.
 This plugin can be used to set-up a Web server where the resources are
 retrieved from geo-distributed
 zenoh storages, each leveraging various backends (file system, database,
 memory...).
 .
 **Library name** `zenoh_plugin_webserver`
 .
 :point_right: **Download stable versions:**
 https://download.eclipse.org/zenoh/zenoh-plugin-webserver/
 .
 :point_right: **Build "master" branch:** see [below](#How-to-build-it)
 .
 -------------------------------
 ## :warning: Documentation for previous 0.5 versions:
 The following documentation related to the version currently in development in
 "master" branch: 0.6.x.
 .
 For previous versions see the README and code of the corresponding tagged
 version:
  -
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.9#readme)
  -
 [0.5.0-beta.8](https://github.com/eclipse-zenoh/zenoh-plugin-webserver/tree/0.5.0-beta.8#readme)
 .
 -------------------------------
 ## **Examples of usage**
 .
 Assuming you have a static website, you can:
  - expose the files as zenoh key/values using the [File System
 backend](https://github.com/eclipse-zenoh/zenoh-backend-filesystem)
  - set-up this Web Server plugin that will allow HTTP clients to browse the
 files.
 .
 Here are the steps:
  1. Make sure the libraries for the File System backend and the Web Server
 plugin are available for the zenoh router:
     either installing their packages (depending your platform), either
 downloading the library files corresponding
     to your platform in your `~/.zenoh/lib` directory.
  2. Copy the website files into a `~/.zenoh/zbackend_fs/my-site` directory (or
 make it a symbolic link to the path of your website)
  3. Create a `zenoh.json5` configuration file containing:
     ```json5
     {
       plugins: {
         webserver: {
           http_port: 8080,
         },
         storage_manager: {
           volumes: {
             fs: {}
           },
           storages: {
             demo: {
               key_expr: "my-site/**",
               strip_prefix: "my-site",
               volume: {
                 id: "fs",
                 dir: "my-site",
                 read_only: true
               }
             }
           }
         }
       }
     }
     ```
  4. Start the zenoh router (`zenohd`). It will automatically load the Web
 Server plugin and make it available on port 8080. It will also create a storage
 replying to any zenoh query on key expressions starting with `my-site/`.
  Now you can browse your site on http://localhost:8080/my-site.
 .
 .
 For more advanced use cases you can also:
  - Have the files of your web sites stored on different hosts. Running a zenoh
 router with a File System Storage on
    each host allow to make all the files available under the `my-site/` zenoh
 key.
  - Duplicate the files of your web sites on several hosts to provide fault
 tolerance.
  - Start several zenoh routers with the Web Service plugin on different hosts
 (not necessarly the same than the
    hosts running the File System storages). Each host will serve your web site.
  - Use other backends than the File System to store your resources and make
 them available through zenoh.
    (List of available backends
 [here](http://zenoh.io/docs/manual/backends-list/)).
  - Deploy a zenoh application that will implement `eval` function for a
 resource, replying to requests with a
    dynamic content (see the `z_eval` example in
    [Rust](https://github.com/eclipse-zenoh/zenoh/blob/master/zenoh/examples/zenoh/z_eval.rs)
 or
    [Python](https://github.com/eclipse-zenoh/zenoh-python/blob/master/examples/zenoh/z_eval.py)).
 .
 -------------------------------
 ## **Configuration**
 .
 In its configuration part, the plugin supports those settings:
  - **`http_port`** - int or string - required:
    either a port number as an integer or a string, either a string with format
 `"<local_ip>:<port_number>"`
 .
 -------------------------------
 ## **Troubleshooting**
 .
 ### *Address already in use*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T14:20:51Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 48, kind: AddrInUse, message: "Address already in use" }
 ```
 It means another process is already using this port number that the webserver
 plugin would like to use.
 In such case, you have 2 solutions:
  - stop the other process using this port
  - make the webserver plugin to another port changing its `listener` option.
 .
 ### *Permission denied*
 If in `zenohd` logs you see such error log at startup:
 ```
 [2021-04-12T13:55:10Z ERROR zenoh_plugin_webserver] Unable to start http server
 for REST : Os { code: 13, kind: PermissionDenied, message: "Permission denied"
 ```
 It probably means your OS (this usually happens on Linux) forbids the usage of
 the configured port for non-root user (actually it usually restricts all ports
 between 0 and 1024).
 In such case, you have 2 solutions:
  - run zenohd with root privileges (via `sudo`)
  - use another changing he webserver plugin's `listener` option.
 .
 -------------------------------
 ## **How to build it**
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 At first, install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html).
 .
 To know the Rust version you're `zenohd` has been built with, use the
 `--version` option.
 Example:
 ```bash
 $ zenohd --version
 The zenoh router v0.6.0-beta.1 built with rustc 1.64.0 (a55dd71d5 2022-09-19)
 ```
 Here, `zenohd` has been built with the rustc version `1.64.0`.
 Install and use this toolchain with the following command:
 .
 ```bash
 $ rustup default 1.64.0
 ```
 .
 And `zenohd` version corresponds to an un-released commit with id `1f20c86`.
 Update the `zenoh` dependency in Cargo.lock with this command:
 ```bash
 $ cargo update -p zenoh --precise 1f20c86
 ```
 .
 Then build the backend with:
 ```bash
 $ cargo build --release -p zenoh-plugin-webserver
 ```
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh-plugin-webserver
Vcs-Git: https://github.com/eclipse-zenoh/zenoh-plugin-webserver

Package: zenohd
Version: 0.7.2-rc
Architecture: armhf
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 6814
Depends: libc6:armhf (>= 2.31)
Filename: 0.7.2-rc/zenohd_0.7.2-rc_armhf.deb
Size: 2212540
MD5sum: e2116545a037c3dd2043426ea3f88cc6
SHA1: 5428cb27f06ea334173c7880f4c772ad3f9b4268
SHA256: fe84aabef472f7ad59c20e24d2e78ef70d3883669e5d4116d2be5bd82dff2c1e
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenohd
Version: 0.7.2-rc
Architecture: amd64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 8080
Depends: libc6 (>= 2.28)
Filename: 0.7.2-rc/zenohd_0.7.2-rc_amd64.deb
Size: 2508556
MD5sum: 978285eed621991b075bffcf4c92f68a
SHA1: b89b7890118386625200b784dcec32ad251dd83c
SHA256: b41501f2e12d5af622b04b6c5b26228f36c22d5e9e6b35595039fa1a76686e9b
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenohd
Version: 0.7.2-rc
Architecture: arm64
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 6904
Depends: libc6:arm64 (>= 2.31)
Filename: 0.7.2-rc/zenohd_0.7.2-rc_arm64.deb
Size: 2251464
MD5sum: 53b2942a0a90c118c4271047456fd095
SHA1: 417b2a3f72e22794f19705a30693779514a4c2c3
SHA256: 1cf737879df5288570603090d821c5d1bb1ce753fd71d882eff42acbb5edbaa5
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

Package: zenohd
Version: 0.7.2-rc
Architecture: armel
Maintainer: zenoh-dev@eclipse.org
Installed-Size: 7010
Depends: libc6:armel (>= 2.31)
Filename: 0.7.2-rc/zenohd_0.7.2-rc_armel.deb
Size: 2219552
MD5sum: c15d79676de3b9d2536d40066ce46610
SHA1: 6f75d4bed797710620bebe4470bad8f3a45329e4
SHA256: e63194554b168a7e0958619e3b47b4221ee80148bd992069003d143a6388e324
Section: net
Priority: optional
Homepage: http://zenoh.io
Description: Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 <img
 src="https://raw.githubusercontent.com/eclipse-zenoh/zenoh/master/zenoh-dragon.png"
 height="150">
 .
 [![CI](https://github.com/eclipse-zenoh/zenoh/workflows/CI/badge.svg)](https://github.com/eclipse-zenoh/zenoh/actions?query=workflow%3A%22CI%22)
 [![Documentation
 Status](https://readthedocs.org/projects/zenoh-rust/badge/?version=latest)](https://zenoh-rust.readthedocs.io/en/latest/?badge=latest)
 [![Discussion](https://img.shields.io/badge/discussion-on%20github-blue)](https://github.com/eclipse-zenoh/roadmap/discussions)
 [![Discord](https://img.shields.io/badge/chat-on%20discord-blue)](https://discord.gg/2GJ958VuHs)
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 .
 # Eclipse Zenoh
 The Eclipse Zenoh: Zero Overhead Pub/sub, Store/Query and Compute.
 .
 Zenoh (pronounce _/zeno/_) unifies data in motion, data at rest and
 computations. It carefully blends traditional pub/sub with geo-distributed
 storages, queries and computations, while retaining a level of time and space
 efficiency that is well beyond any of the mainstream stacks.
 .
 Check the website [zenoh.io](http://zenoh.io) and the
 [roadmap](https://github.com/eclipse-zenoh/roadmap) for more detailed
 information.
 .
 -------------------------------
 ## Getting Started
 .
 Zenoh is extremely easy to learn, the best place to master the fundamentals is
 our [getting started guide](https://zenoh.io/docs/getting-started/first-app/).
 .
 -------------------------------
 ## How to install it
 .
 To install the latest release of the Zenoh router (`zenohd`) and its default
 plugins (REST API plugin and Storages Manager plugin) you can do as follows:
 .
 ### Manual installation (all platforms)
 .
 All release packages can be downloaded from:
  - https://download.eclipse.org/zenoh/zenoh/latest/
 .
 Each subdirectory has the name of the Rust target. See the platforms each
 target corresponds to on
 https://doc.rust-lang.org/stable/rustc/platform-support.html
 .
 Choose your platform and download the `.zip` file.
 Unzip it where you want, and run the extracted `zenohd` binary.
 .
 ### Linux Debian
 .
 Add Eclipse Zenoh private repository to the sources list, and install the
 `zenoh` package:
 .
 ```bash
 echo "deb [trusted=yes] https://download.eclipse.org/zenoh/debian-repo/ /" |
 sudo tee -a /etc/apt/sources.list.d/zenoh.list > /dev/null
 sudo apt update
 sudo apt install zenoh
 ```
 Then you can start run `zenohd`.
 .
 ### MacOS
 .
 Tap our brew package repository and install the `zenoh` formula:
 .
 ```bash
 brew tap eclipse-zenoh/homebrew-zenoh
 brew install zenoh
 ```
 Then you can start run `zenohd`.
 .
 .
 ### Rust API
 .
 -------------------------------
 ## How to build it
 .
 > :warning: **WARNING** :warning: : Zenoh and its ecosystem are under active
 development. When you build from git, make sure you also build from git any
 other Zenoh repository you plan to use (e.g. binding, plugin, backend, etc.).
 It may happen that some changes in git are not compatible with the most recent
 packaged Zenoh release (e.g. deb, docker, pip). We put particular effort in
 mantaining compatibility between the various git repositories in the Zenoh
 project.
 .
 Install [Cargo and
 Rust](https://doc.rust-lang.org/cargo/getting-started/installation.html). Zenoh
 can be succesfully compiled with Rust stable (>= 1.65.0), so no special
 configuration is required from your side.
 To build Zenoh, just type the following command after having followed the
 previous instructions:
 .
 ```bash
 $ cargo build --release --all-targets
 ```
 .
 Zenoh's router is built as `target/release/zenohd`. All the examples are built
 into the `target/release/examples` directory. They can all work in
 peer-to-peer, or interconnected via the zenoh router.
 .
 -------------------------------
 ## Quick tests of your build:
 .
 **Peer-to-peer tests:**
 .
  - **pub/sub**
     - run: `./target/release/examples/z_sub`
     - in another shell run: `./target/release/examples/z_put`
     - the subscriber should receive the publication.
 .
  - **get/queryable**
     - run: `./target/release/examples/z_queryable`
     - in another shell run: `./target/release/examples/z_get`
     - the queryable should display the log in its listener, and the get should
 receive the queryable result.
 .
 **Routed tests:**
 .
  - **put/store/get**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell run: `./target/release/examples/z_put`
     - then run `./target/release/examples/z_get`
     - the get should receive the stored publication.
 .
  - **REST API using `curl` tool**
     - run the Zenoh router with a memory storage:
       `./target/release/zenohd
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, do a publication via the REST API:
       `curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test`
     - get it back via the REST API:
       `curl http://localhost:8000/demo/example/test`
 .
   - **router admin space via the REST API**
     - run the Zenoh router with permission to perform config changes via the
 admin space, and with a memory storage:
       `./target/release/zenohd --adminspace-permissions=rw
 --cfg='plugins/storage_manager/storages/demo:{key_expr:"demo/example/**",volume:"memory"}'`
     - in another shell, get info of the zenoh router via the zenoh admin space:
 .
       `curl http://localhost:8000/@/router/local`
     - get the volumes of the router (only memory by default):
       `curl 'http://localhost:8000/@/router/local/**/volumes/*'`
     - get the storages of the local router (the memory storage configured at
 startup on '/demo/example/**' should be present):
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
     - add another memory storage on `/demo/mystore/**`:
       `curl -X PUT -H 'content-type:application/json' -d
 '{"key_expr":"demo/mystore/**","volume":"memory"}'
 http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore`
     - check it has been created:
       `curl 'http://localhost:8000/@/router/local/**/storages/*'`
 .
 **Configuration options:**
 .
 A Zenoh configuration file can be provided via CLI to all Zenoh examples and
 the Zenoh router.
 .
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file and
 the available options.
 .
 See other examples of Zenoh usage in [examples/](examples)
 .
 -------------------------------
 ## Zenoh router command line arguments
 `zenohd` accepts the following arguments:
 .
   * `--adminspace-permissions <[r|w|rw|none]>`: Configure the read and/or write
 permissions on the admin space. Default is read only.
   * `-c, --config <FILE>`: a [JSON5](https://json5.org) configuration file.
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) shows the schema of this file. All
 properties of this configuration are optional, so you may not need such a large
 configuration for your use-case.
   * `--cfg <KEY>:<VALUE>`: allows you to change specific parts of the
 configuration right after it has been constructed. VALUE must be a valid JSON5
 value, and key must be a path through the configuration file, where each
 element is separated by a `/`. When inserting in parts of the config that are
 arrays, you may use indexes, or may use `+` to indicate that you want to append
 your value to the array. `--cfg` passed values will always override any
 previously existing value for their key in the configuration.
   * `-l, --listen <ENDPOINT>...`: An endpoint on which this router will listen
 for incoming sessions.
     Repeat this option to open several listeners. By default, `tcp/[::]:7447`
 is used. The following endpoints are currently supported:
       - TCP: `tcp/<host_name_or_IPv4_or_IPv6>:<port>`
       - UDP: `udp/<host_name_or_IPv4_or_IPv6>:<port>`
       - [TCP+TLS](https://zenoh.io/docs/manual/tls/): `tls/<host_name>:<port>`
       - [QUIC](https://zenoh.io/docs/manual/quic/): `quic/<host_name>:<port>`
   * `-e, --connect <ENDPOINT>...`: An endpoint this router will try to connect
 to. Repeat this option to connect to several peers or routers.
   * `--no-multicast-scouting`: By default zenohd replies to multicast scouting
 messages for being discovered by peers and clients.
     This option disables this feature.
   * `-i, --id <hex_string>`: The identifier (as an hexadecimal string - e.g.:
 A0B23...) that zenohd must use.
      **WARNING**: this identifier must be unique in the system! If not set, a
 random unsigned 128bit integer will be used.
   * `--no-timestamp`: By default zenohd adds a HLC-generated Timestamp to each
 routed Data if there isn't already one.
     This option disables this feature.
   * `-P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...`: A
 [plugin](https://zenoh.io/docs/manual/plugins/) that must be loaded. Accepted
 values:
      - a plugin name; zenohd will search for a library named
 `libzenoh_plugin_<name>.so` on Unix, `libzenoh_plugin_<PLUGIN_NAME>.dylib` on
 MacOS or `zenoh_plugin_<PLUGIN_NAME>.dll` on Windows.
      - `"<PLUGIN_NAME>:<LIBRARY_PATH>"`; the plugin will be loaded from library
 file at `<LIBRARY_PATH>`.
 .
     Repeat this option to load several plugins.
   * `--plugin-search-dir <DIRECTORY>...`: A directory where to search for
 [plugins](https://zenoh.io/docs/manual/plugins/) libraries to load.
     Repeat this option to specify several search directories'. By default, the
 plugins libraries will be searched in:
     `'/usr/local/lib:/usr/lib:~/.zenoh/lib:.'`
   * `--rest-http-port <rest-http-port>`: Configures the [REST
 plugin](https://zenoh.io/docs/manual/plugin-http/)'s HTTP port. Accepted
 values:
       - a port number
       - a string with format `<local_ip>:<port_number>` (to bind the HTTP
 server to a specific interface)
       - `"None"` to desactivate the REST plugin
 .
     If not specified, the REST plugin will be active on any interface (`[::]`)
 and port `8000`.
 .
 > :warning: **WARNING** :warning: : The following documentation pertains to the
 v0.6+ API, which comes many changes to the behaviour and configuration of
 Zenoh.
 To access the v0.5 version of the code and matching README, please go to the
 [0.5.0-beta.9](https://github.com/eclipse-zenoh/zenoh/tree/0.5.0-beta.9) tagged
 version.
 .
 -------------------------------
 ## Plugins
 .
 > :warning: **WARNING** :warning: : As Rust doesn't have a stable ABI, the
 plugins should be
 built with the exact same Rust version than `zenohd`, and using for `zenoh`
 dependency the same version (or commit number) than 'zenohd'.
 Otherwise, incompatibilities in memory mapping of shared types between `zenohd`
 and the library can lead to a `"SIGSEV"` crash.
 .
 By default the Zenoh router is delivered or built with 2 plugins. These may be
 configured through a configuration file, or through individual changes to the
 configuration via the `--cfg` CLI option or via zenoh puts on individual parts
 of the configuration.
 .
 > :warning: **WARNING** :warning: : since `v0.6`, `zenohd` no longer loads
 every available plugin at startup. Instead, only configured plugins are loaded
 (after processing `--cfg` and `--plugin` options). Once `zenohd` is running,
 plugins can be hot-loaded and, if they support it, reconfigured at runtime by
 editing their configuration through the adminspace.
 .
 Note that the REST plugin is added to the configuration by the default value of
 the `--rest-http-port` CLI argument.
 .
 **[REST plugin](https://zenoh.io/docs/manual/plugin-http/)** (exposing a REST
 API):
 This plugin converts GET and PUT REST requests into Zenoh gets and puts
 respectively.
 .
 **[Storages plugin](https://zenoh.io/docs/manual/plugin-storages/)** (managing
 [backends and storages](https://zenoh.io/docs/manual/backends/))
 This plugin allows you to easily define storages. These will store key-value
 pairs they subscribed to, and send the most recent ones when queried. Check out
 [DEFAULT_CONFIG.json5](DEFAULT_CONFIG.json5) for info on how to configure them.
 .
 -------------------------------
 ## Troubleshooting
 .
 In case of troubles, please first check on [this
 page](https://zenoh.io/docs/getting-started/troubleshooting/) if the trouble
 and cause are already known.
 Otherwise, you can ask a question on the [zenoh Discord
 server](https://discord.gg/vSDSpqnbkm), or [create an
 issue](https://github.com/eclipse-zenoh/zenoh/issues).
Vcs-Browser: https://github.com/eclipse-zenoh/zenoh
Vcs-Git: https://github.com/eclipse-zenoh/zenoh

