dicej opened issue #4303:
Per https://github.com/bytecodealliance/wit-bindgen/issues/259, I'm interested in upgrading the
wasmtime
dependency inwit-bindgen
, and that has raised a more general question, which I'd like to ask here:What's the vision for code which previously used module linking and will eventually need to transition to the component model? Will there be a simple recipe to follow, or will big (e.g. architectural) changes be necessary?
Whatever that vision is, I'd be interested to help implement it if there are opportunities to do so without distracting from the work already in progress.
dicej commented on issue #4303:
I hijacked today's wasmtime project meeting to discuss this and had a very enlightening conversation with @alexcrichton and @fitzgen about it. Here are my takeaways:
- Users of module linking should stick with pre-0.36
wasmtime
for the time being. Although it's technically possible to migrate to the component model already (i.e.wasmtime
has enough of the building blocks to make module linking work), the rest of the ecosystem has not caught up and can't catch up until more foundation work is done, and trying to use it in this state would not be worth the trouble.- There are a few specific opportunities to help with that foundation work now, and once that's done the ecosystem work will be very parallelizeable; i.e. many more opportunities will arise. I've volunteered to help with this, and Alex and Nick are going to open issues to track a couple of the foundation work items.
- The long-term vision for linking modules will be component-oriented, e.g.
wasmtime_wasi::add_to_linker
would take acomponent::Linker
.@alexcrichton perhaps you could clarify the last point, since I'm not sure I understood it. Would there be two variants of
add_to_linker
, one for modules and one for components? Or would bothLinker
types implement a trait so thatadd_to_linker
could be generic? Or wouldcomponent::Linker
simply replace the moduleLinker
and subsume the latter's functionality such that instantiating a module is the same as instantiating a trivial component containing a single module?
alexcrichton commented on issue #4303:
Sure yeah, my current thinking is that
wit-bindgen
will only generate oneadd_to_linker
function which will only work with components, not with core wasm modules. Much of the component model only makes sense in the context of the component model itself (e.g. async, resources, streams, etc) so I don't think it will be possible to have a full-featured generated for "just" core wasm. This means that in the long run support for running raw core wasm files will likely be dropped fromwit-bindgen
since it'll work primarily at the ocmponent layer.
alexcrichton commented on issue #4303:
Also, for concrete work items, I'm trying to keep the main tracking issue up-to-date and the "Separate work items" category should all be issues that are standalone (ish) and possible to implement in parallel. (although I still wouldn't classify any of them as "easy")
dicej commented on issue #4303:
I think the original questions here have been addressed, so I'm going to close this. Thanks for your help, Alex!
dicej closed issue #4303:
Per https://github.com/bytecodealliance/wit-bindgen/issues/259, I'm interested in upgrading the
wasmtime
dependency inwit-bindgen
, and that has raised a more general question, which I'd like to ask here:What's the vision for code which previously used module linking and will eventually need to transition to the component model? Will there be a simple recipe to follow, or will big (e.g. architectural) changes be necessary?
Whatever that vision is, I'd be interested to help implement it if there are opportunities to do so without distracting from the work already in progress.
Last updated: Dec 23 2024 at 12:05 UTC