Open yowl opened 8 months ago
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?
I'm looking forward to learn more from this experiment. 👀
Questions
wit-bindgen
able to generate streams and futures ? Notes about browser implementation (for context)
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.
- are streams and futures already available in wasmtime
Streams (defined as resource
s 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, (resource
s) 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
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.
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 haveHttpClient
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?