opentimestamps-client
opentimestamps-client copied to clipboard
Implement watchlist cache and runtime cache
Overview
Sometimes I forget to upgrade my timestamps, and I'd like to keep them upgraded. Instead of searching my filesystem for all immature timestamps, why not track them with the ots cache?
Various other improvements are included, as described below.
Note that it may be prudent to refactor the upgradewatchlist
command to be responsible for removing items from the watchlist, instead of the upgrade
command. Doing this in the upgrade
command might be very slow when the watchlist is enormous, which would make for a bad user experience when the user is only trying to upgrade a single timestamp. However, it is not clear why a user would prefer to upgrade a single timestamp and not all timestamps anyway...
Commit message
A watchlist cache is implemented. The watchlist is a list of immature timestamp files that should be upgraded at a later time. When a file is timestamped, its file path is added to the watchlist. The file is removed from the watchlist once it has been successfully upgraded.
Immature timestamps no longer immediately cause exit of the program, and instead an error is sent to stderr followed by a continuance of the program until the very end when the program exits with exit(1).
A runtime cache is implemented. It is based on the premise that it is unlikely that a timestamp will be upgraded in the time that it takes to run the whole command, so the calendar servers will only be checked once per each new commitment. This is particularly useful for bulk upgrading of timestamps. If "immediate exit" was still implemented, this would not be possible. Without a runtime cache, checking each timestamp against each calendar server-- even with the same root commitment-- would be unbearably slow.