Add redesign note to decouple sleep from sensor

[khatus.git] / README.md

diff --git a/README.md b/README.md
index 5381f90..601bf4c 100644 (file)
--- a/README.md
+++ b/README.md
@@ -54,10 +54,10 @@ now, is superfluous), so now it is essentially a pub-sub - parallel publishers
 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.
@@ -183,3 +183,12 @@ Redesign notes
 
 - 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).