subscribers that can filter-out what they need and then do whatever they want
with the data. Status bar is one such subscriber:
-`P1 > pipe&; P2 > pipe&; ... PN > pipe&; tail -f pipe | tee >(S1) >(S2) ... >(SN) > /dev/null
+`P1 > pipe&; P2 > pipe&; ... PN > pipe&; tail -f pipe | tee >(S1) >(S2) ... >(SN) > /dev/null`
The cool thing is that, because the pipe is always read (`tail -f ... > /dev/null`),
-the publishers are never blocked, so we get a live stream of event to which we
+the publishers are never blocked, so we get a live stream of events to which we
can attach any number of interested subscribers (` ... tee ... `) and, because
the pipe is named, if a subscriber needs to - it too can publish something to
the pipe without being blocked.
- controller should not do formatting
- need in-memory db for diskless feedback/throttling and cache
+- decouple sensor execution from sleep, i.e. a sensor is blocked not by sleep
+ process directly, but by reading of a pipe, to where a sleep process will
+ write a message announcing interval completion and thus signaling execution.
+ This will allow us to manually signal a sensor to update (concretely - I just
+ openned my laptop from sleep and want to force the weather to update
+ immediately); likewise, the sleep process should be blocked on pipe-read
+ until sensor execution is complete - this will allow us to reconfigure
+ intervals at runtime (which seems like a better idea than the above in-memory
+ DB one).