# Yukon design megathread

**URL:** <https://forum.opencyphal.org/t/yukon-design-megathread/390>\
**Category:** Yukon\
**Created:** [March 12, 2019, 8:26pm UTC](https://forum.opencyphal.org/t/yukon-design-megathread/390 "2019-03-12T20:26:06Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [March 26, 2019, 3:43pm UTC](https://forum.opencyphal.org/t/yukon-design-megathread/390/19 "2019-03-26T15:43:44Z")

</div>

> [@Zarkopafilis](#):
>
> - Mutable registers only, show as clickable (blue anchor tag).
> - Persistency / Volatility show up in a different column named ‘Lifetime’ (or recommend something better).

If we’re going to aggregate registers by name, the columns will be used for the node dimension, so there won’t be any free columns left for mutability/volatility (and possibly other flags which we may add in the future). I would instead recommend to display flags in the same cell as the parameter value (together with other parameter metadata). Different parameters sharing the same name may be mutable on one node and immutable on other nodes.

From the above indirectly follows that we probably shouldn’t hide any registers unless the user explicitly requested that. For example, the set of filters that you described later might also include options for mutability and persistency.

> [@Zarkopafilis](#):
>
> Regarding the concurrent node configure, maybe we can have a checkbox that switches the view of available registers: based on selected nodes and/or selected register names. For example, you can type in some regex to match the nodes, and/or some regex (or text) for the parameter you want to change. These filters run independently but result in a set of nodes and parameters that are shown: Of course, as an error prevention feature, only the nodes that have the parameter listed are being contacted through the API. We can have some extra check on the popup register edit window that selects nodes and upon the press of the ‘Update Register(s)’ button, shows which nodes failed to accept the changes (did not report back new value).

Yes, this makes sense. It might also be useful to allow the user to multi-select several register cells on the same row and then click some button to bulk-edit them, but it can be done incrementally. Please keep in mind that in theory, some nodes may not support the standard service `uavcan.node.GetInfo`, which means that we won’t be able to know their names, and the only way to select them would be to specify their node ID manually. Although our experience with UAVCAN v0 seems to indicate that implementers tend to always support this service.

For example, a user may want to see registers that match the following filters:

- the node name matches `some_vendor.*` (suppose this is a wildcard); this automatically removes all nodes whose name we don’t know, e.g. which do not support `uavcan.node.GetInfo`.
- the register name matches `uavcan.*`.
- show only persistent mutable registers (i.e., only configuration parameters).

> [@Zarkopafilis](#):
>
> What’s the format to expose each individual’s register details? For example, do we send a list out of all the register names existing? (That means, each client needs to parse each individual one by name, decide which have min/max/default values based on $name[\<|\>|=]) Instead, we can do that on the backend and send the response in the current-ish format, which contains all the information for one register-details object, including the min/max/default values. The second one is my preferred way, which is more user-friendly on the client consuming the API. This does not mean that you are prohibited from querying each parameter by name: If you specify a name that ends with \>\<=, other parameters of that register (ex. current value, or the other min/max/default ones) are not queried.

Take my response with a grain of salt, but I would actually prefer the first way, because in that case you can implement the whole register thing without introducing any special logic on the backend side. You will merely need a generic service invocation API: the frontend tells the backend to invoke a service such-and-such on the node so-and-so; the backend does that and simply returns the response structure as-is. It’s up to you, but the first case seems simpler, provided that you are okay with implementing the register type checking and input validation on the frontend.

> [@Zarkopafilis](#):
>
> How are the [Primitives](https://github.com/UAVCAN/dsdl/tree/uavcan-v1.0/uavcan/primitive) going to be exposed as a register’s data type? Instead of providing an enum of possible data types, we could have a field showing it’s object type [scalar, array, empty, string, unstructured] and if that object type is scalar or array, we can have an extra item type [bit, int natural, real] as well as a bit length type (not for bits) [2~64].

Maybe it’s better to find a generic way of representing DSDL objects in JSON, and then use that model everywhere, including the register management logic? I recall @scottdixon said that he made something to that end.

---

_[View the full topic](https://forum.opencyphal.org/t/yukon-design-megathread/390)._