Closed lukewagner closed 3 months ago
Another piece of the puzzle that this explainer is missing is that the dynamic shared-everything linking can also be achieved with a component which imports a core module of a given signature.
Minor quibble: that would still be an instantiation-time operation rather than a runtime one, so I don't think it quite qualifies as "dynamic". But yes, I expect that will be a hugely useful feature; I'd love for componentize-py
to optionally produce components that import libpython312.so
instead of bundling it. And being able to host such modules in a well-known registry would make that a no-brainer.
Given that wasm-compose is already deprecated in favor of wac, I think it should be left out of this explainer.
Done
Another piece of the puzzle that this explainer is missing is that the dynamic shared-everything linking can also be achieved with a component which imports a core module of a given signature.
Ah, good point. That is yet another orthogonal aspect (since, as long as you have a registry available) you can import any time you could have nested. I suppose that would be good to cover. I'll have to think about how to succinctly describe and visualize that in the diagram...
@pchickey and others: I added two paragrams and some visuals to the diagram in this commit, PTAL
Also @lann, it'd be useful to hear if the blurbs make sense to you, since the PR mentions wasm-pkg-tools
now.
(I added an FAQ entry.)
This PR adds the diagram discussed in #239 along with some surrounding explanatory text that tries to paint a higher-level picture of the combined use of shared-everything/-nothing linking allowed by the component model. It also tries to define some of the terms used to describe linking. Definitely folks let me know if anything sounds off or doesn't accurately reflect the current state of tooling.
(cc @sunfishcode @alexcrichton @dicej )