Caching for "offline mode"

[huyz]

What would be the best way to do this with bkt, if possible:

I want to run a command which requires online mode: either internet access or a volume to be mounted. If online, then great, the output of the command is displayed and cached by bkt. If offline, then the command either returns a specific exit code or specific output, which bkt detects and thus outputs the cached output from the last successful (online) invocation, plus a clear indication that this cached output is an "offline cache" that is "X minutes", "X hours" old (up to 24 hours, beyond which a simple ISO8601 date is printed to show how stale this cached output is).

[dimo414]

#24 sounds related, if you'd like to weigh in there. I am open to adding something like this, it's not quite what you're asking about but maybe you'd be able to use it.

I don't anticipate adding support to bkt to detect something like "is offline" since that's a fairly complex thing to detect in general (as simple as it seems when talking colloquially about it 🙂) and because I want bkt to remain agnostic to the commands it executes and caches. Similarly, I don't have plans to add behavior to bkt to output different content when a result is cached vs. fresh - it is intended to be transparent to callers. The command could obviously output when it ran (e.g. via date), but it wouldn't be able to compute the time delta.

That said, there are a few things you could consider:

• I recently added support for using a file's modtime as a cache key; I haven't used this feature extensively yet but I can imagine it being a fairly powerful hook for triggering invalidations. It might be something you could hook into. I'm also entertaining the idea of not requiring a --ttl at all if --modtime is used.
• You could also possibly use the --discard-failures flag; this doesn't help get back the prior output (which will have expired by the time bkt calls the backing command again and discovers it has failed), but might still be a useful building block, for example if you used a long --ttl and used --force --discard-failures to refresh the cache on a more frequent timeline.
• bkt is a library in addition to a CLI binary, and the library exposes additional hooks, notably whether a result was cached (and it's age) or freshly generated. I am open to adding more functionality to the library even if that functionality isn't appropriate for the CLI, and would welcome feedback and feature requests on the library APIs.

One last thing to call out; it's possible you can get something simpler working without bkt. Obviously I'd love if you find bkt useful but if you end up building a bunch of wrapper logic to massage bkt into doing what you want it might be simpler to just manage your cached data yourself. Just something to keep in mind as you experiment.