You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off, thank you for making this project! I'm baffled by the decision to reject Component Model on the grounds that it's not a W3C recommendation (who even cares about W3C in this day and age anyway?)
Could you shed some light on how much work remains until gravity could run wasi-http + wasi-filesystem payloads? I looked through the other issues but I'm missing a lot of context.
Hey @whitequark! It is a strange stance for Wazero to take, but my understanding is that they were just applying logic after a decision was already made (stemming from wider community drama against the Component Model).
As for the status, I believe there are 3 main things that block wasi-p2:
Needs to support Resources, which wasi-p2 (particularly wasi-http) uses heavily: Implement Resources #5
Only works with a single Component, while wasi-p2 requires shared-nothing linking due to the dependency tree of components that it composes from: Implement shared-nothing linking #28
Of course, there are small things like figuring out how to represent things more appropriately between WIT and Go (Options are currently val, ok but that doesn't doesn't work for options as record fields), but I think those would be fleshed out as the instructions are added.
Thank you! Of these, I'd say (3) scares me the most. (Regretfully I don't think I'll be in a position to work on the other issues any time soon, but for reasons that have nothing to do with technology or OSS.)
The shared-nothing linking also scares me 🙈 I was hoping to use Wazero's ImportResolver to avoid implementing the linking dance that jco needs to perform, but it still hasn't been promoted from "experimental" and I haven't had time to investigate (that reminds me to go add that to the linked issue).
Piggy-backing on this issue slightly, if I understand correctly, 3. shouldn't be a problem for single components that simply rely on being able to importwasi:http/outgoing-handler (or something similar), right? Because all of the WASI implementations are likely to be provided by the host, rather than by a linked component? 🤔
@sd2k My understanding is any import is a separate component with its own instantiation. This is how jco works where it creates a separate instance for each and links them together. You'd have to use some tool to combine multiple components into a single but avoid providing externals; perhaps I am out-of-date but last I looked there wasn't a tool that would selectively combine without providing all imports.
Activity
blaine-arcjet commentedon Sep 22, 2025
Hey @whitequark! It is a strange stance for Wazero to take, but my understanding is that they were just applying logic after a decision was already made (stemming from wider community drama against the Component Model).
As for the status, I believe there are 3 main things that block wasi-p2:
Of course, there are small things like figuring out how to represent things more appropriately between WIT and Go (Options are currently
val, okbut that doesn't doesn't work for options as record fields), but I think those would be fleshed out as the instructions are added.whitequark commentedon Sep 22, 2025
Thank you! Of these, I'd say (3) scares me the most. (Regretfully I don't think I'll be in a position to work on the other issues any time soon, but for reasons that have nothing to do with technology or OSS.)
blaine-arcjet commentedon Sep 22, 2025
No worries!
The shared-nothing linking also scares me 🙈 I was hoping to use Wazero's ImportResolver to avoid implementing the linking dance that
jconeeds to perform, but it still hasn't been promoted from "experimental" and I haven't had time to investigate (that reminds me to go add that to the linked issue).sd2k commentedon Oct 21, 2025
Piggy-backing on this issue slightly, if I understand correctly, 3. shouldn't be a problem for single components that simply rely on being able to import
wasi:http/outgoing-handler(or something similar), right? Because all of the WASI implementations are likely to be provided by the host, rather than by a linked component? 🤔blaine-arcjet commentedon Oct 22, 2025
@sd2k My understanding is any
importis a separate component with its own instantiation. This is howjcoworks where it creates a separate instance for each and links them together. You'd have to use some tool to combine multiple components into a single but avoid providing externals; perhaps I am out-of-date but last I looked there wasn't a tool that would selectively combine without providing all imports.