You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The second research step before implementing the real stubless RPC linker. Based on #1148 we know exactly what amount of type information we need to do that hardcoded mapping from wasmtime's internal representation into our RPC representation.
The outcome of this ticket is to have a way to get this information in the worker executor for an arbitrary component.
Some approaches to choose from:
analyse the component model data just like we do for finding exported functions
use the embedded binary wit custom section
upload extra metadata (wits, or preprocessed information) from client side
The text was updated successfully, but these errors were encountered:
It is possible that we don't need actual type information - as the component is already parsed and we have what wasmtime exposes. In this case maybe adding a generic "dynamic linked interface" lists to component metadata would work, where you would have to list the dynamic stubs in your app manfest and this would get into the component metadata with optional "linker-specific payload" which we don necessarily need to use here, but can be useful for dynamic grpc/openapi stubs etc.
The second research step before implementing the real stubless RPC linker. Based on #1148 we know exactly what amount of type information we need to do that hardcoded mapping from wasmtime's internal representation into our RPC representation.
The outcome of this ticket is to have a way to get this information in the worker executor for an arbitrary component.
Some approaches to choose from:
The text was updated successfully, but these errors were encountered: