Authors:Kyle Sunden


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

Table of Contents


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:

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


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/ 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.


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