add virtualization doc

[wanderer]

This PR attempts to sketch out what the overloaded term "virtualization" mean, why we might want it and how it might be accomplished.

[MarkMcCaskey]

Is the reason to use inheritance over composition here because of other OOP types defined in the IDL?

Being able to arbitrarily combine interfaces without the restrictions of a hierarchy is something I'm interested in if this grows beyond WASI

[wanderer]

ohh i really messed this up. I copied the wrong file here!!! :S please move to #64

[sunfishcode]

This document introduces the concepts of "static" and "dynamic" virtualization, however it appears to only discuss "dynamic" virtualization, with techniques to essentially create vtable-like objects which would expose the API functions.

This paper describes a path which enables virtualizating static APIs dynamically by making modules first-class objects. From what I understand, this would seem to fit wasm fairly well, as it would allow us to continue to use static bindings for many cases, but still virtualize APIs. I'd be interested in what you think of this approach.

[lukewagner]

Agreed with @sunfishcode. I've also discussed the rough idea with @erights and it seemed like it would indeed be possible to base an ocap-style runtime-polymorphic system on top of a lower-level, more-static virtualization mechanism like what's in the paper Dan linked to. I think it would end up being expressed as a "layered on top of core wasm" spec, just like, and quite complementary to, Interface Types.

Unfortunately, we don't yet have even an explainer-level writeup of how the idea in the paper maps concretely down to wasm. Personally, I'm interested to help write an initial sketch so that we can get a Stage 0 proposal repo to discuss more, but I need to make some more progress on getting Interface Types written up before starting. I'd also be happy to collaborate with anyone who wants to start sooner.

[Chatina73]

Remove changes

[revmischa]

Suggested change

	Virtualization in the context of WASI interfaces is the ability for a Webassembly module to implement a given interface and consumer module to be able to use that implement transparently.
	Virtualization in the context of WASI interfaces is the ability for a Webassembly module to implement a given interface and for a consumer module to be able to use its implementation transparently.

[revmischa]

Suggested change

	Furthermore there are two classes of virtualization; static and dynamic. Static virtualization is done before the initialization of a Wasm store and dynamic at runtime.
	Furthermore there are two classes of virtualization: static and dynamic. Static virtualization is done before the initialization of a Wasm store and dynamic is performed at runtime.

[revmischa]

Suggested change

Roughly taken from [here](https://pdfs.semanticscholar.org/4cce/9abb177cc58c199e13b82d498f37010c2bfc.pdf). Lets say a user wants to encrypt a text file they are editing. One way this could be accomplished is by having composable services. An encryption module could export the interface for a directory that would encrypt any file written to it. Lets consider how this could be done with in the framework of WASI. At runtime the encryption module would given a root directory file descriptor in which it would write encrypted text to, it would also would return a wrapped file descriptor of a directory that would be given to the text editor to write in. This means any WASI `fd` related calls that the text editor makes would handled by the encryption module which would then interact base system. Lets look next at a WASI program might accomplish virtualizing the file descriptor interface.

Roughly taken from [here](https://pdfs.semanticscholar.org/4cce/9abb177cc58c199e13b82d498f37010c2bfc.pdf). Let's say a user wants to encrypt a text file they are editing. One way this could be accomplished is by having composable services. An encryption module could export the interface for a directory that would encrypt any file written to it. Let's consider how this could be done with in the framework of WASI. At runtime the encryption module would given a root directory file descriptor in which it would write encrypted text to, it would also would return a wrapped file descriptor of a directory that would be given to the text editor to write in. This means any WASI `fd`-related calls that the text editor makes would handled by the encryption module which would then interact with the base system. Let's look next at how a WASI program might accomplish virtualizing the file descriptor interface.

[revmischa]

Suggested change

	Assuming the function reference proposal, another way to implement dynamic dispatching currently would be to create a primitive polyfill for structs. An `fd` would then be represented as a stuct who's fields contained all the associated functions
	Assuming the function reference proposal, another way to implement dynamic dispatching currently would be to create a primitive polyfill for structs. An `fd` would then be represented as a struct whose fields contain all the associated functions.

[sunfishcode]

Virtualization in WASI is now described in the Design Principles document which has now landed, in the section on interposition (meaning "virtualization" in the sense used here), which lays out a vision. In short, the "verbs" are imported functions, and the "nouns" are handle values. This describes the "more static" version described by Luke above.

If there are any questions or concerns about this approach, or anything that's unclear, feel free to file issues or bring them to the WASI Subgroup meetings.