richlander commented 11 months ago

WASI Developer Experience Goals

WebAssembly System Interface is an exciting technology. Lots of work has already gone into enabling C# with WASI. dotnet/runtime #65895 defines a set of low-level requirements for providing a working implementation. We can up-level that into a set of developer experience goals.

The following are proposed changes in various categories. Please propose your own.

Related (interview about WASI and C#): https://www.youtube.com/watch?v=fnAjxzMPPqk

Building

Remove requirement for runtimeconfig.template file.
Enable building single file wasm files by default (which may require installing the WASI SDK with the workload).
Enable publishing AOT with a gesture similar to PublishAot.

Running

Enable using Wasm runtime args with dotnet run (otherwise dotnet run isn't generally useful).
Remove the existing dotnet run "helpful" output.

Programmability

Enable importing popular WASI functionality (possibly worlds) as NuGet packages.
Import other WASI functionality with a reference to a WIT file.
Import Preview 2 components.
Enable async with WASI interfaces.
Enable HttpClient as-is (particularly for https endpoints).
Enable minimal APIs (for handling Web requests).

More detailed work breakdown https://github.com/dotnet/runtime/issues/65895

jkotas commented 11 months ago

cc @yowl @silesmo

ghost commented 11 months ago

Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.

Issue Details

# WASI Developer Experience Goals [WebAssembly System Interface](https://github.com/WebAssembly/WASI) is an exciting technology. Lots of work has already gone into enabling [C# with WASI](https://devblogs.microsoft.com/dotnet/extending-web-assembly-to-the-cloud/). [dotnet/runtime #65895](https://github.com/dotnet/runtime/issues/65895) defines a set of low-level requirements for providing a working implementation. We can up-level that into a set of developer experience goals. The following are proposed changes in various categories. Please propose your own. Related (interview about WASI and C#): https://www.youtube.com/watch?v=fnAjxzMPPqk ## Building - Remove requirement for `runtimeconfig.template` file. - Enable building single file wasm files by default (which may require installing the WASI SDK with the workload). - Enable publishing AOT with a gesture similar to `PublishAot`. ## Running - Enable using Wasm runtime args with `dotnet run` (otherwise `dotnet run` isn't generally useful). - Remove the existing `dotnet run` "helpful" output. ## Programmability - Enable importing popular WASI functionality (possibly worlds) as NuGet packages. - Import other WASI functionality with a reference to a WIT file. - Import Preview 2 components. - Enable async with WASI interfaces. - Enable `HttpClient` as-is (particularly for `https` endpoints). - Enable minimal APIs (for handling Web requests).

Author:	richlander
Assignees:	-
Labels:	`arch-wasm`, `untriaged`, `needs-area-label`
Milestone:	-

ReneeGA2020 commented 10 months ago

Enable building single file wasm files by default

Hopefully, it still allow me to do false to opt out. As my workload requires standalone files to be compiled separately.

Also, a question about WIT importing. the WIT file spec does not seem to leave any room for object's 'instance' reference. The 'interface' in WIT were mapped into statics funtions in C#. My understanding is that not all wasm supported language are OOP. Still, it's not so great if I'm a lib wrote by an oop language but I cannot expose an oop method to a consumer lib that was also wrote by n oop language. Not sure if the .NET team will try to do some extra things around that.

yowl commented 10 months ago

Not sure if the .NET team will try to do some extra things around that.

This scenario is probably handled in the component model MVP with WIT resources . e.g.

resource blob {
    constructor(init: list<u8>);
    write: func(bytes: list<u8>);
    read: func(n: u32) -> list<u8>;
    merge: static func(lhs: borrow<blob>, rhs: borrow<blob>) -> blob;
}

wit-bindgen for c# does not currently support resources, hopefully this month we will have something.

jpflueger commented 10 months ago

This is super exciting! I'm not a contributor here but I work at Fermyon and we have a serverless webassembly project called Spin. We've built an SDK around Steve Sanderson's Wasi SDK previously and I have tried to update it for dotnet 8 with some success but I have a couple of suggestions/questions.

It would be nice to be able to use a library project that doesn't require a main function and have the output wasm be a wasi preview 2 component. I think this would be implied by Enable building single file wasm files by default but I just wanted to make sure.

Will Enable minimal APIs (for handling Web requests). be targeting the wasi-http spec (specifically wasi:http/incoming-handler)?

yowl commented 10 months ago

It would be nice to be able to use a library project that doesn't require a main function

This is should be supported now by the NAOT compiler option, I'm not sure where the mono interpreter is with that. However the SDK from Steve needs updating I believe.

Regards HTTP, there is https://github.com/dotnet/runtimelab/issues/2468 where some conversation has taken place, but nothing more as far as I know. Could be there is work internal to Microsoft as I'm just an outside contributor.

richlander commented 10 months ago

Hi @jpflueger! We're well aware of your work on Spin. It would be good to talk about moving the two projects forward in some coordinated way. This includes how spiderlightning fits into the picture.

library project that doesn't require a main function

Yes. That's a good goal / scenario.

minimal APIs

I haven't talked to the Web team, but implementing that on top of wasi-http makes sense to me.

silesmo commented 10 months ago

We have the same need at nor2 for wasi-http for our runtime n2. So that's definitely a goal to be able to support @jpflueger.

ReneeGA2020 commented 9 months ago

Speaking of dotnet run, will dotnet test also available for wasi? Or what is Microsoft's plan for best practice of unit testing on wasi?

flibbertigibbet-uk commented 9 months ago

Async between WASI components authored in different language runtimes looks particularly gnarly to implement, at least that was the impression given at the Bytecode Alliance plumbers summit a few weeks ago.

I would gladly accept an interim release minus async support if it enables experimental WASI preview-2 development on .Net 9 a few months earlier.

tschneidereit commented 9 months ago

@flibbertigibbet-uk the complications around async composition between components shouldn't really impact the toolchain here, which should be able to target the entirety of WASI preview2 without issues.

dotnet / runtime