Skip to content

Support for wasi-http #95

Open
Open

Description

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

Activity

  1. blaine-arcjet commented on Sep 22, 2025

    @blaine-arcjet
    Contributor

    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.

  2. whitequark commented on Sep 22, 2025

    @whitequark
    Author

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

  3. blaine-arcjet commented on Sep 22, 2025

    @blaine-arcjet
    Contributor

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

  4. sd2k commented on Oct 21, 2025

    @sd2k
    Contributor

    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? 🤔

  5. blaine-arcjet commented on Oct 22, 2025

    @blaine-arcjet
    Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions