Wasmtime GitHub notifications bot (Jul 14 2021 at 11:58): Wasmtime GitHub notifications bot (Jul 14 2021 at 11:58):srenatus opened issue #3085:
Feature
For embedding wasmtime, i.e., usage via a language bindings, it would be nice if the config cache related settings could be provided via API calls, not config files.
Benefit
For use cases embedding wasmtime, it might not be desirable to expose the config file to users of the project that's using wasmtime inside. Furthermore, deploying a configuration file, and handling its absolute path is cumbersome for deployment.
E.g. if there's a CLI application that's using wasmtime, and the user would download the executable and run it, we'd either have to
- create a config in a temp directory on the fly and remove it afterwards, or
- instruct the user to put a config into the right place
Implementation
It would be nice if the compilation cache settings were exposed in the same way other settings are -- sketching in Go, it could be
func (*Config) SetCache(enabled bool) func (*Config) SetCacheDirectory(path string)etc.
Alternatives
Maybe what I'm thinking about here would be abusing the cache system? :thinking: I don't know...
Wasmtime GitHub notifications bot (Jul 14 2021 at 15:38):alexcrichton commented on issue #3085:
FWIW the caching system is relatively old in Wasmtime and hasn't seen many updates since it was originally added. I suspect that this was the intention all along, it's just that no one got around to it!
I personally think it'd be good to add programmatic configuration like this. One other possible option is along the lines of how cranelift is configured where string key/value pairs are provided instead of a method-per-configuration-option. That's a bit more flexible for future additions and reduces the API surface area too in theory.
Last updated: Dec 23 2024 at 13:07 UTC