Component model support

[JanProvaznik]

Context

https://github.com/bytecodealliance/wasmtime/tree/main/examples/component
Add support for making the same example from C#.

https://github.com/WebAssembly/component-model/tree/main
https://github.com/bytecodealliance/componentize-dotnet

Current state:

Only Wasm modules can be instantiated and functions ran from them. Loading .wasm file which is compiled as a component into a Module fails.

Steps

[ ] running components
[ ] imports and exports (with WIT data types)
[ ] converting modules to components
[ ] multiple components interacting

Remarks

This is blocked by bytecodealliance/wasmtime#8036 (comment)

[jsturtevant]

Now that we released wasmtime v22 support, we should have the right version but may need to expose some new apis

[JanProvaznik]

Related:
other language bindings have varying support
bytecodealliance/wasmtime-py#245
bytecodealliance/wasmtime-go#204
bytecodealliance/wasmtime#7801

[jsturtevant]

Since we use the c-api we need bytecodealliance/wasmtime#8036.

[BasGeertsema]

I'm also very much interested in supporting Wasm Component.

The wasmtime 33 release and 34 release expanded the C api to support (some aspects of) Wasm Components.

This is encouraging and it seems we can make some progress here as well?

[jsturtevant]

Yes, the project could begin to consume those. Its does need a refresh to pick up the latest wasmtime versions

[BasGeertsema]

Yes, the project could begin to consume those. Its does need a refresh to pick up the latest wasmtime versions

I have created a PR for the refresh: #332

[cyraid]

Good job on the refresh btw!

Thinking about the component model, how would it work? Could we dress up some classes with attributes like Microsoft's clearscript?

[BasGeertsema]

Good job on the refresh btw!

Thinking about the component model, how would it work? Could we dress up some classes with attributes like Microsoft's clearscript?

I did some experimental development efforts to support components. In contrast with core Wasm, the Component Model supports complex types such as string, list, result variant, option and record. The design seems to be influenced by ML-enthousiasts ;)

The challenge will be to have an ergonomic mapping between mainstream C# types (List<>, struct, class, enum, etc.) and these types in the Component Model. Some will be straight forward, such as List<> and string. Other mappings such as to variant and result will be less natural as there is no de-facto standard equivalent in C#. As another example, a subtle complication is that the char type in Component Model is defined as holding a unicode scalar value, which is 32 bits. Where as the char in C# is 16 bit. Should we map the char to a C# char and throw exceptions when out of range or should we map it to a byte[], uint or int ?

Besides the mechanics of mapping values there are also the WIT interface files. There are code generators for various languages to generate interface code based on a WIT file. Perhaps this functionality should be in wasmtime-dotnet as well, or perhaps it should be in a separate package?

So, with respect to wasmtime-dotnet I expect the implementation of the component model to be more opionated than the rest of the code. Imo we should strive towards a lower-level and flexible interface, with a higher-level interface on top. Not unlike the System.Text.JSON serialization where you can easily (de)serialize objects using the high-level interface but can utilize the low-level interface if you require that kind of control. For example, wasmtime-dotnet could provide a Result type out of the box for convenience, but also allow applications to supply their own Result type.

This feature is not trivial to implement and will be opionated by its nature. A way forward would be to implement the low-level mechanics first and then start building the high-level interfaces and WIT interfacing on top of that.

[ero-qt]

uint is likely the appropriate type for a unicode scalar. In C#, such a type is represented with the Rune struct. Encoding.UTF32 may be of help in case the char type can be used as parts of a string.

[martindevans]

For example, wasmtime-dotnet could provide a Result type out of the box for convenience, but also allow applications to supply their own Result type.

Just a note on this, wasmtime-dotnet actually does something similar for functions already. See Result.cs and demo use in tests.

A function that returns int from wasm can be wrapped like this:

var func = instance.GetFunction<int>("func_name"); // Throws on trap
var func = instance.GetFunction<FunctionResult<int>>("func_name"); // Result indicates trap

Rune

One complication is that type doesn't seem to be supported in netstandard2.0 or netstandard2.1, which we support (see: https://github.com/bytecodealliance/wasmtime-dotnet/blob/main/src/Wasmtime.csproj#L4C6-L4C22)