pub enum Reading {
Values(Vec<(&'static str, bool)>),
Unavailable(String),
}Expand description
What an addon’s signals read at one moment.
§Why the daemon asks rather than the addon telling
Polled, not pushed, and the reasons are all about what happens when this interface crosses a process boundary — which FR-045 says it will.
A request/response call survives that move unchanged. A callback does not: it needs a reverse channel, and a reverse channel is precisely where a wedged addon becomes a wedged daemon, because something has to be waiting on it.
Polling also puts the rate limit on the side that suffers from getting it wrong. A pushing addon that reports a flapping signal thousands of times a second is a churn source the daemon can only damp after paying for it, and ADR-0011 is explicit that signal churn is flash wear rather than a slow link. A polled addon cannot produce that by construction.
What polling costs is answered by the addon, not by the poll rate: an implementation is free to keep a cache fed by platform events and answer from it, which is what FR-065’s “no measurable idle CPU” actually turns on.
Variants§
Values(Vec<(&'static str, bool)>)
It looked, and these are the values.
Ids must be ones Addon::signals declares. Anything else is dropped
by the daemon rather than becoming a signal nobody can find the
definition of.
It could not look, and this is why.
FR-064: every signal it publishes then reads false, and the reason is this sentence rather than “the condition was false”. The two states are indistinguishable to a user and have different fixes — one is a configuration mistake, the other is a closed application.