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
We should provide *.wit files for lunatic's host functions. WIT (WebAssembly Interface Types) files are definitions of higher level types and function signatures that describe an API that the Wasm host is exporting and the guest is importing. It can also be an interface between two Wasm modules in the component model.
For example, the WASI functions that are provided by lunatic have a formal spec in the *.wit file format, but none of the other ones (networking, process spawning, messages, ...) do. I think we should also create them! However, this will result in some breaking API changes.
There are two main benefits in providing such a spec:
Even if we don't end up using the automatically generated bindings, following the canonical ABI proposal for host functions will result in wider support from guests. Lunatic is already exposing an unspecified inconsistent ABI that is fairly similar to the proposal. So, why not go a step further and just use the standard everyone is using?
This will also give us an opportunity to go over all the existing host functions and remove inconsistencies.
The text was updated successfully, but these errors were encountered:
We should provide
*.wit
files for lunatic's host functions. WIT (WebAssembly Interface Types) files are definitions of higher level types and function signatures that describe an API that the Wasm host is exporting and the guest is importing. It can also be an interface between two Wasm modules in the component model.For example, the WASI functions that are provided by lunatic have a formal spec in the
*.wit
file format, but none of the other ones (networking, process spawning, messages, ...) do. I think we should also create them! However, this will result in some breaking API changes.There are two main benefits in providing such a spec:
Even if we don't end up using the automatically generated bindings, following the canonical ABI proposal for host functions will result in wider support from guests. Lunatic is already exposing an unspecified inconsistent ABI that is fairly similar to the proposal. So, why not go a step further and just use the standard everyone is using?
This will also give us an opportunity to go over all the existing host functions and remove inconsistencies.
The text was updated successfully, but these errors were encountered: