fix(bklog):Fix gap in duration times

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

diff --git a/exec/bkgpslog-plan.org b/exec/bkgpslog-plan.org
index e1009621d3bad384cc5dbee9826144696b12f0bc..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,10 @@ 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
 ** 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