Cache downloaded images
Opened this issue · 2 comments
We should respect some of the basic properties for image caching (with an easy way to clear the cache), so that we can avoid repeating a bunch of image calls if we have a valid cached image already. This should also speed up what seems to be the slowest visual part of document load times when we have a warm cache
Hashing out some of the details here
The cache
Currently I'm thinking of using something like redb for the cache itself. It's a pretty minimal pure-rust embedded database which should work well for our needs
Entries
The key itself would be the local path or url for the image. There's a bit of care involved to avoid bad keys where the local path should be resolved to an absolute path, and URLs that are hosted locally should likely be ignored from the cache
The actual image data itself will likely still just be the LZ4 compressed raw image data like how things are currently stored in memory. We should also version this format so that we can change the format in the future without to hack around things (keying by the path+version would allow for multiple versions to co-exist simultaneously which could be good)
Validity
For local files this should be as simple as storing and comparing the file's modified time to know if the cached entry is still valid
For local URLs we'll likely just always avoid caching outside of a single session
For remote URLs there's a lot more to consider in terms of storing and comparing the ETag and relevant Cache-Control information
Garbage Collection
We don't want the cache to grow forever, so we'll need to add some form of garbage collection. At the very least there should be a size limit on the cache (maybe default to something like 64MiB or 128MiB?) with maybe an LRU eviction policy?
It would also be nice to have a TTL (time-to-live) for each entry as well which should keep the cache small for people who only infrequently use inlyne. Having a TTL would also play well with cache-control for remote images since we can evict based on that as well
This can just be a once per session background task that kicks off after everything else finishes
CLI
There's enough functionality that having an inlyne cache subcommand would likely make sense. We could have functionality for cleaning the cache, showing stats, etc.
There's a lot involved here. I'll go ahead and start chipping away at things