Support for wasi-http

[whitequark]

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.

[blaine-arcjet]

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:

1. Missing codegen for a lot of WIT instructions: Implement remaining instructions #14
2. Needs to support Resources, which wasi-p2 (particularly wasi-http) uses heavily: Implement Resources #5
3. 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.

[whitequark]

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]

No worries!

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).

[sd2k]

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]

@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.