-
Notifications
You must be signed in to change notification settings - Fork 22
feat: add basic scaffolding for wasi http #85
feat: add basic scaffolding for wasi http #85
Conversation
|
There's discussion that is relevant here: |
|
I have sent a PR here to the |
|
Thanks for filing this and sorry for the race condition and taking so long to get a PR up! I'm happy to discuss more and compare the different approaches in wasi-http/#3 if that sounds good to you. |
|
Thanks. I am glad to get the discussion started. Just to be clear that my main goal is the outbound HTTP request. So I believe it would be nice to get that fleshed out first (basically because it is simpler) in order to have this PR merged. Don't you agree? |
|
Don't forget about local server development using HTTPS and WebSocket, or QuickJS and txiki.js which has wasm3 support out of the box. Node.js is not the only JavaScript runtime. Folks are using QuickJS and txiki.js to, among other reasons, get away from the 40MB V8 minimal runtime load. |
|
@eduardomourar @brendandburns et al: from various discussions spread around many repos it sounds like there is rough alignment in the Bytecode Alliance to start implementing WebAssembly/wasi-http#3, see how it shakes out, and feed whatever we learn back into the spec, just as we're doing with other foundational wasi proposals in this repo. There is still lots of design to work out, but I think there is enough known at this point to start dividing up and conquering an actual implementation of wasi-http PR#3. This PR is a great concrete step in the right direction, but there is still lots to iterate on so that it meets with the standards proposal, which is considerably more complex. I'd like to get together a (small) set of bytecode alliance contributors who can dedicate time over the next month to hack on this. Lets have a meeting next week to find alignment, and do some project planning so we don't step on each others toes too much. Please let me know who to invite and some available meeting times on zulip, or email phickey at fastly. |
|
@pchickey, as discussed I will leave this open here until we have the basic scaffolding in place for the wasi-http definition. Then, @brendandburns and I will start to implement each trait in the host focusing on the outgoing aspect first. |
pchickey
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Some small comments, and then one significant chunk of stubs is missing
|
Just to be clear that the rust host has been implemented for wasmtime in this PR: bytecodealliance/wasmtime#5929 |
This adds a basic scaffolding for WASI HTTP proposal as defined here.
Based on different definitions:* https://github.com/fermyon/spin/blob/main/wit/ephemeral/http-types.wit* https://github.com/deislabs/spiderlightning/blob/0adcb768becee393bbcddfd1fdd69790d7de5d4c/wit/http-types.wit* https://github.com/lapce/wasi-experimental-http/blob/main/witx/wasi_experimental_http.witx* https://github.com/extism/extism/blob/f0f53c782769783ea5a84919cdf828e56ab1f20a/manifest/src/lib.rs