doc(time):Create README for time server setup

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

diff --git a/exec/bkgpslog-plan.org b/exec/bkgpslog-plan.org
index 3e43633ef757b193be9dd556e84a5cad07da5801..cc5c8390219147363ee8f319111733b706c32f5b 100644 (file)
--- a/exec/bkgpslog-plan.org
+++ b/exec/bkgpslog-plan.org
@@ -1,3 +1,6 @@
+2020-07-12T21:16Z; bktei> Note: This file is now retired since ~bklog~
+has replaced ~bkgpslog~.
+

 * bkgpslog task list
 ** DONE Add job control for short buffer length
    CLOSED: [2020-07-02 Thu 16:04]
 * bkgpslog task list
 ** DONE Add job control for short buffer length
    CLOSED: [2020-07-02 Thu 16:04]


@@ -60,7 +63,8 @@ done
 
 Raspberry Pi Zero W shows approximately 71ms of drift per buffer round
 with 10s buffer.
 
 Raspberry Pi Zero W shows approximately 71ms of drift per buffer round
 with 10s buffer.

-** TODO Feature: Recipient watch folder
+** DONE Feature: Recipient watch folder
+   CLOSED: [2020-07-12 Sun 21:08]

 2020-07-03T21:28Z; bktei> This feature would be to scan the contents
 of a specified directory at the start of every buffer round in order
 to determine encryption (age) recipients. This would allow a device to
 2020-07-03T21:28Z; bktei> This feature would be to scan the contents
 of a specified directory at the start of every buffer round in order
 to determine encryption (age) recipients. This would allow a device to


@@ -95,7 +99,11 @@ to watch. When examining the directory, check for a file with the
 appropriate file extension (ex: .pubkey) and then read the first line
 into the script's pubKey array.
 
 appropriate file extension (ex: .pubkey) and then read the first line
 into the script's pubKey array.
 

-** TODO Feature: Simplify option to reduce output size
+2020-07-12T21:08Z; bktei> ~-R~ watch directory option added in ~bkgpslog~ ver
+~0.4.0~.
+
+** DONE Feature: Simplify option to reduce output size
+   CLOSED: [2020-07-12 Sun 21:15]

 
 ~gpsbabel~ [[https://www.gpsbabel.org/htmldoc-development/filter_simplify.html][features]] a ~simplify~ option to trim data points from GPS
 data. There are several methods for prioritizing which points to keep
 
 ~gpsbabel~ [[https://www.gpsbabel.org/htmldoc-development/filter_simplify.html][features]] a ~simplify~ option to trim data points from GPS
 data. There are several methods for prioritizing which points to keep


@@ -126,7 +134,16 @@ about 450.
 152K relerror-1000.kml
 #+END_EXAMPLE
 
 152K relerror-1000.kml
 #+END_EXAMPLE
 

-** TODO Feature: Generalize bkgpslog to bklog function
+2020-07-12T21:13Z; bktei> Instead of programming data simplification
+in ~bkgpslog~, the data simplification step should be performed via
+~bklog~'s ~-p~ option which specifies a processing command string to
+be ~eval~'d before data is compressed, encrypted, and written to
+disk. In other words, handling the simplification of data beyond
+allowing for a general command string specified by ~-p~ is outside the
+scope of ~bkgpslog~ or its successor ~bklog~.
+
+** DONE Feature: Generalize bkgpslog to bklog function
+   CLOSED: [2020-07-12 Sun 21:11]

 2020-07-05T02:42Z; bktei> Transform ~bkgpslog~ into a modular
 component called ~bklog~ such that it processes a stdout stream of any
 external command, not just ~gpspipe -r~. This would permit reuse of
 2020-07-05T02:42Z; bktei> Transform ~bkgpslog~ into a modular
 component called ~bklog~ such that it processes a stdout stream of any
 external command, not just ~gpspipe -r~. This would permit reuse of


@@ -160,7 +177,12 @@ unsure in my ability to program script that could run for long periods
 of time without causing a runaway usage of memory. I still think it's
 a good idea to offer a script TTL option to the user but I think the
 default should be to simply run forver.
 of time without causing a runaway usage of memory. I still think it's
 a good idea to offer a script TTL option to the user but I think the
 default should be to simply run forver.

-** TODO: Evaluate ~rsyslog~ as stand-in for this work
+
+2020-07-12T21:11Z; bktei> ~bklog~ script created and tested as of
+commit ~aedd19f~.
+
+** DONE TODO: Evaluate ~rsyslog~ as stand-in for this work
+   CLOSED: [2020-07-12 Sun 21:09]

 2020-07-05T02:57Z; bktei> I searched for "debian iot logging" ("iot"
 as in "Internet of Things", the current buzzword for small low-power
 computers being used to provide microservices for owners in their own
 2020-07-05T02:57Z; bktei> I searched for "debian iot logging" ("iot"
 as in "Internet of Things", the current buzzword for small low-power
 computers being used to provide microservices for owners in their own


@@ -222,6 +244,27 @@ 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.
 

+2020-07-12T21:10Z; bktei> rsyslog is outside the scope of what
+~bkgpslog~ does (record location observations). A different tool
+should be used to retrieve and synchronize data. The dumb storage
+method of "tar files in a syncthing folder" works for now.
+** 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