Added more predefined scalar messages
Checks WiFi status
Spawns separate thread for client_sync (reading the network)
Most all log messages are now INFO (to be shown by default)
Closes#300
Signed-off-by: Tom Marble <tmarble@info9.net>
Allows a variable to be set to the EMPTY string
- by not setting a value `/set myvar`
During initialization now verifies that PDDB is mounted.
Added warnings for PDDB not mounted and WiFi not connected.
- the WiFi check is not yet implemented
Signed-off-by: Tom Marble <tmarble@info9.net>
Adds migrations framework
Delays mtxcli initialization until first user input, because we know:
- PDDB is mounted
- Timer is stable
- User actually using mtxcli
Adds send_async_msg scalar_async_msg
- basis for automatically updating chatroom
Signed-off-by: Tom Marble <tmarble@info9.net>
Adds migrations framework
- Migration for v0.9.11-0120: update the filter
Filter
- narrow filter to only the fields and events for the current room
Introduces "read only" variables (e.g. __version).
Signed-off-by: Tom Marble <tmarble@info9.net>
`vault` is changed so that instead of clearing the list of
data each time the screen is updated, it tries to compare it
against the existing data and modifies the record if it needs to,
or leaves it untouched.
Furthermore, at least in the password path, temporary strings
are pre-allocated and re-used, instead of freed and re-allocated
every time through the main loop.
The combination of these optimzations reduces the time to re-parse
a couple hundred records from about 1000ms to 200ms, reducing the
overall time to retrieve the database from 1.8s to 1.0s. It also
makes the loop much more stable over time; previously, as the heap
fragmented, performance would slowly degrade. Now that most
records are static and re-used, the performance seems to stay
constant.
The framwork is also put in place to re-use TOTP/U2F records,
but the code still uses the legacy method of clearing the
entire stored list and rebuilding it. However, it wasn't deemed
a priority to fix this because generally I haven't seen use cases
where users have hundreds of tokens or TOTP's; so long as the
number is about 20 or so, the performance difference should
be imperceptible with or without optimization.
This refactors the remaining vault accessor routines to use
the new more efficient key pre-fetching routine. This also
fixes up an error in test case generation and hopefully resolves
an issue with concurrency errors using the older version of
the access routine.
