yaq-yeps/313

has-dependents

Abstract ¶

This YEP defines the has-dependents trait for yaq daemons which control other yaq daemons.

Table of Contents ¶

Motivation ¶

In some complex systems it is convinient to create "wrapper" daemons. These wrappers might offer a simplified or alternative "higher-level" interface to a collection of "lower-level" hardware interface daemons. Such higher-level daemons can be more reusable---the lower-level daemons can be interchanged while keeping the same high-level interface code in place. As an example, yaqd-attune provides a simplified interface to an optical parametric amplifier made up of many discrete motors.

Certain clients would benefit from knowing inter-daemon dependencies. For example, when making a best effort live plot, a client might choose to use the wrapper daemon's position as the independent variable and hide the lower-level daemons. This YEP provides a simple way for clients to request this metadata. These layers of daemon access provide information to clients about relationships between hardware, including but not limited to:

• Which devices should be considered "top level" and increased in prominence to the user
• Which devices are available for operations such as tuning which require special treatment for dependent hardware
• Which devices should be accessible by nice syntax (e.g. parent.child notatation)

The concept for this trait is already in use in yaqc-bluesky.

Specification ¶

Message: get_dependent_hardware ¶

response: {'type': 'map', 'values': 'string'}

Returns a mapping of names to host:port strings which specify the yaq daemon of dependents. Clients are expected to remap localhost/127.0.0.1 hosts to the host where they contact the parent daemon. Dependents are not gauranteed to be accessible to clients which can access the parent. As such, some parent daemons MAY provide methods to read/write attributes of dependents.

Rejected Ideas ¶

Require specific config ¶

Each daemon has unique ways of determining what the dependents are. Some will only ever accept one hardware, some a list. Some even have separate categories of dependent hardware that are treated differently in implementation (e.g. attune daemon opa motors vs delay stages). Thus a consistent form for specifying dependent daemons ends up being obtuse for some daemons or under specified for others. It is recommended that the config is well documented and accepts at least host:port strings, possibly port integers on localhost as well.

Copyright ¶

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.

built 2023-10-10 23:52:42                                      CC0: no copyright