The current proxy_set_shared_data and proxy_get_shared_data hostcalls are synchronous. If a host environment wants to provide a remote shared data store with higher latency, offering async/callback-style variants of these hostcalls would fit that use case.
What's the portability and migration story here? Contrary to WASI (or "future WASI"?), we need "colored" functions for sync/async variants, which means that plugins using "sync KV" would need to move to "async KV" interfaces when migrating to hosts with async KV stores. We could potentially force everybody to "async KV" interface and short-circuit the path for local KV, but that would result in pretty ugly plugin code with the existing SDKs.
More generally, aren't HTTP/gRPC callouts sufficient to integrate with existing Cloud KV/SQL/Storage services? Do we want to provide abstraction to those at the host level?
For consideration for the next ABI revision:
The current
proxy_set_shared_data
andproxy_get_shared_data
hostcalls are synchronous. If a host environment wants to provide a remote shared data store with higher latency, offering async/callback-style variants of these hostcalls would fit that use case.