Closed Michael-F-Bryan closed 1 week ago
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Feel free to reopen the issue if it has been closed by mistake.
Motivation
There are many places across the Wasmer CLI and WASIX where we want to use caching to avoid unnecessary work. At the moment, each of these places is hand-rolling its own caching solution.
Off the top of my head, I can think of the following:
wasmer_wasix::runtime::resolver::WapmSource
- caches the response of aGetPackage()
query against the registrywasmer_wasix::runtime::module_cache
- contains various implementations of caches for WebAssembly modules (in-memory, thread-local, filesystem, etc.)wasmer_wasix::runtime::package_loader::BuiltinPackageLoader
- caches*.webc
files downloaded from the registrywasmer_wasix::runtime::resolver::WebSource
- caches*.webc
files downloaded from the internet via a bare URLThese caching solutions all tend to have the same properties or requirements:
wasmer
runsshared_buffers::OwnedBuffer
) them rather than reading into memoryETag
header or hash has changed, or whateverProposed solution
I was thinking of creating a concrete type with an API similar to a
HashMap<CollectionName, HashMap<Key, Value>>
, except it'll pass out instances ofshared_buffer::OwnedBuffer
and automatically manage the synchronisation of on-disk and in-memory caches.This would probably hook into Wasmer Edge's caching facilities, too.
Additional context
This originally came up when I was working on #3983. Having one or two places where we do caching is fine, but I noticed I was doing the same in-memory/on-disk dance in several places and all of it is essentially untested.