lukewagner
commented
11 months ago I think you're right that we need a way to spawn a new component at runtime; there are plenty of great use cases for that (some already documented in the Component Model's UseCases.md here. When you dig into how efficient linkage and lifetime management (of these component instances) should work, I think the right place to add this functionality is in the Component Model directly, as a runtime-callable variant of the existing instantiate expression, returning an owned handle to the new instance. (Early in the process of proposing the Component Model, I had this slide showing the spectrum of options and their implications, and "runtime instantiate" corresponds to the second-to-leftmost column.) Unfortunately, I think this might take a bit more time (I think it's the next big feature to add after native async support, although perhaps some of the work is parallelizable with async).
I know this involves a lot of design work and problems to tackle. Yet, in the long run I think the need for spawning wasm components will arise. In my naive view the interface would expect the binary component code and allow for composition to, e.g., pass stdin stream data and read stdout stream data from the currently running component. Since this consumes new host memory, the spawning is allowed to fail due to runtime memory limits.
One could emulate this behavior by running a wasm interpreter (since bytecode generation would not help) but it bloats the overall binary size and the speed of the spawned component would be slow. Also, I think that this would be the last piece in a real "wasm OS" where the part that compositions components does not need to be native code and thus any wasm runtime can run it. Think about a simple wasm shell - one can do this in native code or JS for the browser but not in wasm as of now.