debug(bklog):Test more direct tar --append operation

[EVA-2020-02.git] / exec / bkgpslog-plan.org

diff --git a/exec/bkgpslog-plan.org b/exec/bkgpslog-plan.org
index 3e43633ef757b193be9dd556e84a5cad07da5801..e1009621d3bad384cc5dbee9826144696b12f0bc 100644 (file)
--- a/exec/bkgpslog-plan.org
+++ b/exec/bkgpslog-plan.org
@@ -222,6 +222,23 @@ think converting ~bkgpslog~ into a ~bklog~ script that appends
 encrypted and compressed data to a tar file for later extraction
 (possibly the same script with future features) would be best.
 
 encrypted and compressed data to a tar file for later extraction
 (possibly the same script with future features) would be best.
 

+** TODO: Place persistent recip. updates in asynchronous coproc
+2020-07-06T19:37Z; bktei> In order to update the recipient list, the
+magicParseRecipientDir() function needs to be run each buffer period
+in order to scan for changes in the recipient list. However, such a
+scan takes time; if the magicGatherWriteBuffer() function must pause
+until magicParseRecipientDir() completes, then a significant pause
+between buffer sessions may occur, causing detectable gaps in location
+data between buffer rounds.
+
+I looked for ways in which I might start magicParseRecipientDir()
+asynchronously immediately before running the data collection command
+and then collect its output at the start of the next buffer round. One
+way using the ~coproc~ Bash built-in is described [[https://stackoverflow.com/a/20018504/10850071][here]]. I'd have to
+make the asynchronous function output the recipient list to stdout
+which would then be ~read~ into the ~recPubKeysValid~ array in the
+main loop. However, for now, I'm putting the magicParseRecipientDir()
+as-is in the main loop and accepting the delay for now.

 * bkgpslog narrative
 ** Initialize environment
 *** Init variables
 * bkgpslog narrative
 ** Initialize environment
 *** Init variables