Provide a RID for WASM

[terrajobst]

We need to provide a RID for WASM. My proposal is to call it wasm.

@ericstj I'm not sure if this node should be connected to anything in the RID graph, but my assumption is no. Also, is runtime the right repo or should this be moved elsewhere?

@rrelyea @marek-safar @mhutch @lewing @SteveSandersonMS @danroth27

[marek-safar]

Yes, this is right repo. We should clarify what RID will be the parent of wasm?

[ericstj]

So we currently have the RID webassembly with architecture wasm which derives from unix.

runtime/src/libraries/pkg/Microsoft.NETCore.Platforms.Future/runtimeGroups.props

Lines 8 to 11 in 95b7248

	<RuntimeGroup Include="webassembly">
	<Parent>unix</Parent>
	<Architectures>wasm</Architectures>
	</RuntimeGroup>

If folks agree on this, we can promote it to the primary platforms package, it's currently in the Future package.

[marek-safar]

I don't think unix is right parent. What rid name do you suggest based on this, is it webassembly1.0-wasm ?

[ericstj]

The RIDs this generates are here:

runtime/src/libraries/pkg/Microsoft.NETCore.Platforms.Future/runtime.json

Lines 3 to 16 in 95b7248

	"unix-wasm": {
	"#import": []
	},
	"webassembly": {
	"#import": [
	"unix"
	]
	},
	"webassembly-wasm": {
	"#import": [
	"webassembly",
	"unix-wasm"
	]
	}

What should be the parent? Linux? Nothing at all (peer of Unix/Win)? Keep in mind that the RID parent here isn't likely to impact native assets since there won't be any with wasm architecutre. It'll likely impact managed code. Runtime libraries could be a case study, in the cases where we cross-compile which assets are most likely to work? Does webassembly expose platform libs similar to Unix or Linux?

[marek-safar]

I think the parent should be either nothing at all (peer of Unix) or something WebAssembly specific (like wasm). It will depend on how the platform will evolve but I can imagine building managed libraries (under src/libraries) for two different RIDs where one is browser-based and one is WASI based where we have a dependency on system calls or we want to take advantage of the web environment.

The RID graph then could look like

		wasm
		/ 	\
wasm-wasi	wasm-browser

[ericstj]

Platform API availability / similarity is the thing to look at, also, where do we see our PAL.

For example the Unix lets us create a library PAL at this layer and implement it for each platform. That way we have single IL and implement the differences in the system.native.* PAL. Is a PAL at this layer feasible for webassembly or do you think it would need a totally different definition and therefor a parallel implementation for anything that cross-compiles between win and unix today?

[marek-safar]

For example the Unix lets us create a library PAL at this layer and implement it for each platform.

system.native.* PAL libraries won't be unix as they are compiled into native code which will be wasm byte code in our case. If there is a case where we have fully managed library which pinvokes into libc (and you consider libc to be unix) then both wasi and emscripten (wasm-browser) emulate it but the implementation is not 100% compatible. The same layer could emulate win32 API or other OS APIs.

We could start with Unix but I am worried that this will limit us in the future as we'll be forced to maintain unix compatibility for no good reason.