Noted in #63 that learnt state from a device might be useful to persist in a file, and some of it restored when the program restarts. Such as the last timestamp of the last received message, last known readings, last known switch state, etc.
POSSIBLE: 9. understand read only and read/write intents better
when using configuration data and last known values, it is useful
to keep them in the same single file, so it is easy to copy
to other machines. Some data is naturally 'write once' and
very configuration based. Some data is naturally 'write often'.
It might be nice if these two types of data could appear in the same
file, but the locking/performance and resilience issues be handled
differently for the two classes of data - e.g. perhaps having
two connections to the same database file, one in read only mode
for config records, and one in read/write mode for last use data.
There might also be different namespace prefixes in the file
so that the key sets are separate, or there may be a way to
link them so that when you read a record you get both the static
config data and the fast changing last use data as a single
record. But this then implies when you do an update, you
probably want to update part of a record rather than the
whole record.
Noted in #63 that learnt state from a device might be useful to persist in a file, and some of it restored when the program restarts. Such as the last timestamp of the last received message, last known readings, last known switch state, etc.
POSSIBLE: 9. understand read only and read/write intents better
when using configuration data and last known values, it is useful to keep them in the same single file, so it is easy to copy to other machines. Some data is naturally 'write once' and very configuration based. Some data is naturally 'write often'. It might be nice if these two types of data could appear in the same file, but the locking/performance and resilience issues be handled differently for the two classes of data - e.g. perhaps having two connections to the same database file, one in read only mode for config records, and one in read/write mode for last use data. There might also be different namespace prefixes in the file so that the key sets are separate, or there may be a way to link them so that when you read a record you get both the static config data and the fast changing last use data as a single record. But this then implies when you do an update, you probably want to update part of a record rather than the whole record.