silicon-heaven/libshvclient-rs

A Rust framework for Silicon Heaven RPC devices

SHV Client library for Rust

This is a library implementing client functionality with device capabilities according to SHV specification.

It is currently unstable, going through a heavy development and architecture changes.

Origin

The project originated in an early development stage of SHV for Rust, from the device example at rev. e740fd301dc65f3412ad1154595bf61ee5632aba. It is being developed as a separate project having shv-rs as a dependency.

libshvclient-rs's Issues

Request handlers generation by macros

It would be convenient to put boilerplate error handling and response generation code to macros and write only procedures that handle already checked method and param of a RPC request.

Support `ls` for inner nodes with children

Let's say we have node A which also handles its child nodes prop_a_1, prop_a_2 and we want to mount another nodeB into subdir:

* A
  | - prop_a_1
  | - prop_a_2
  \ - subdir
           \ * B
               | - prop_b_1
               \ - prop_b_2

We need that ls called on path A returns all its children: ["prop_a_1", "prop_a_2", "subdir"]

Wrapper for ClientCommand sender

Instead of calling client_cmd_tx.unbounded_send(ClientCommand::RpcCall { request: (), response_sender: () }, better have a wrapping object with methods, e.g. make_rpc_call(request: RpcMessage) -> Receiver<RpcFrame>

Testing

Parametrized .app and .device nodes

These nodes are described in SHV spec and at least .app should be implemented by every client even if it does not implement any tree. The .app is accessible in clients directory on the broker.

Documentation

Dynamic mounts

Sometimes a client app needs to mount its nodes after the initialization.

We can have two types of dynamic mounts:

1. Nodes that are mounted once at some point and then their structure persist during the application run
2. Nodes that implement interface to some dynamic data, so the subtree structure may differ with each access

The methods description has to be provided for each path. Handlers will provide its own dir and ls implementations.
Provide two variants of the mount method, or parametrize with an enum.

Consider allowance of 'nested' mounts on nodes that already have (or can have) its own properties (#2) .

Resolve `dir` method in the library code

Since the library first gets methods in order to check access level, it can handle dir right away. There is no way that custom handlers could resolve this method differently.

Subscriptions for individual signals

Notifications are subscribed per path for all signals on a path. Sometimes it's needed to subscribe only a specific signal.

Also if there are more matching subscriptions for a path, a signal should be delivered to all subscribers of that path and prefix paths.

Check permissions