Wasm components as replacement for lower level, e.g. libc implementations. Such as HTTP/time/random

[yowl]

Wasi and Wasm components are providing some "worlds" or interfaces over functionality such as HTTP (https://github.com/WebAssembly/wasi-http). From a user perspective, if you were targeting wasm-wasi and wanted to use HTTP, it seems like it would be nice to continue to use System.Net.Http.HttpClient, set some build option and have HttpClient switch to importing the WIT world and allowing the implementation to be supplied as a component.

Other Wasi components exists (and are dependencies of wasi-http), such as random, and time. Same would apply there. Is that an area that would be appropriate here in runtimelab, or are there deeper conversations that Microsoft would want to have internally first?

[jkotas]

HttpClient implemented on top of wasi-http makes sense as part of wasm/wasi story. I think runtimelab is a good place to start experimenting with this, give that these wasi interfaces are not very baked and changing frequently.

@pavelsavara @maraf @SteveSandersonMS @lewing Do you have anything to add?

[pavelsavara]

I'm looking forward to learn more from this experiment. 👀

Questions

• are streams and futures already available in wasmtime ?
• is C# wit-bindgen able to generate streams and futures ?
• And more in general, what's the state of wit-bindgen for C#? Is there demo I could try ?

Notes about browser implementation (for context)

• only some browsers could do streaming request/response. We have C# options API to opt-in into that, otherwise the default is whole request/response.
• therefore WASI in browsers may have similar limitations. And different hosts will behave differently.
• there are CORS and other headers by which the host would limit the possible operations.
• cookies, redirection, SSL, authentication features of C# API are not possible in browser
• synchronous APIs of the C# API are throwing PNSE, because we can't block the browser event loop
• dotnet has good unit test suite
• part of the test suite is assuming that unit test can use sockets (to play the server side part of the test). This is great for testing various timing issues. Since we don't have sockets in the browser, we use WebSocket + controlled web server out of browser process.

[pavelsavara]

I guess HTTP server/kestrel would be separate stream of work ?
Does it make sense to wait with implementing it until we learn from HTTP client or work on it in parallel ?

Maybe https://github.com/microsoft/reverse-proxy could be great test case.

[yowl]

• are streams and futures already available in wasmtime

Streams (defined as resources in wit terminology) are in wasi preview2 and wasmtime supports those. Async, future is planned for preview 3. In preview2 there is a pollable type which can be polled perhaps through an event pump. Could make some parts of HttpClient at least temprorarily dependent on such a pump.

is C# wit-bindgen able to generate streams and futures ?

streams, (resources) is in development, hopefully we will have something in January. future keyword is in preview 3, so nothing is being done for that currently.

And more in general, what's the state of wit-bindgen for C#? Is there demo I could try ?

Some tests are passing, strings, numbers for example. We are building out support for preview 2 in https://github.com/bytecodealliance/wit-bindgen. As for a demo, the easiest thing is the work Steve Sanderson has been doing on a SDK, https://github.com/dotnet/dotnet-wasi-sdk However we may have just broken that by updating the packages from 8 to 9, and including support for the new WasmImportLinkageAttribute

[yowl]

I guess HTTP server/kestrel would be separate stream of work ?

wasi-http does include an interface for incoming connections, so would be related, but probably separate, if I understand where you are coming from correctly.