Brooks Townsend (Dec 18 2023 at 23:24): Brooks Townsend (Dec 18 2023 at 23:24):Hey folks, I was looking for a wasi:http stream but couldn't find one. Just wanted to see if wasi:http had any plans for Websockets, or if that's something that would fall under a different interface
Mossaka (Joe) (Jan 02 2024 at 23:46):I think that standardizing wasi:websockets totally makes sense but there are some interesting design questions raised by @Luke Wagner when we had an exchange on this idea.
IIRC, the most difficult question is how to design the wasi:sockets world given the fact that it's a long-lived connection. Surely we can have a Wasm module that takes "keepalive" imports and keeps running for as long as the connection lives (for hours or even for days), but that creates a lot of memory waste. Shall we serialize the states and have an export that acceptes the saved states before that host kills the Wasm instance?
Joel Dice (Jan 03 2024 at 16:54):I suspect we'll end up wanting two separate worlds for websockets: one that assumes the guest instance lives as long as the connection, and another (serverless-friendly) one that assumes the guest is only instantiated long enough to handle immediately-available events (e.g. connection initiation and incoming frames) and then shut down until more events are available. The latter implies that any long-lived state would need to be stored using e.g. wasi:key-value rather than in guest memory.
I've done a fair amount of design work on the latter world already. My plan was to experiment with it in Spin and then start working on an official WASI standard based on that experience. Happy to collaborate in a broader forum if there's interest, though.
Luke Wagner (Jan 03 2024 at 16:58):That separation makes a lot of sense to me; I expect there will be rather-differently-shaped use cases for each of those two worlds and so you want to be somewhat declarative about which one you're targetting. For the long-lived world, one possibly-useful litmus test I've been thinking about is: it might be a good goal to design WASI WebSockets such that it's possible for componentize-js to implement the CloudFlare Hibernatable WebSockets API.
Joel Dice (Jan 06 2024 at 00:07):FWIW, I've created a proposal to add inbound, serverless-style support for WebSockets to Spin: https://github.com/fermyon/spin/pull/2212
Mossaka (Joe) (Jan 08 2024 at 19:17):@Joel Dice would you like to propose wasi:websockets on WASI subgroup meeting this week? I'd love to get the momentum going.
Joel Dice (Jan 08 2024 at 19:26):I'm a "prototype-first" kind of person, so I'd prefer to get something working first, fine-tune the interfaces in the process, and then propose the result as a standard. IMHO, none of the wasi-cloud proposals so far gained much momentum until people started implementing them, so I expect that proposing the standard will not, itself, get momentum going.
Joel Dice (Jan 08 2024 at 19:33):I certainly won't object if a "proposal-first" person wants to step up and get that started, though :)
Milan (Oct 16 2024 at 19:48):Looks like the proposal pr went in, curious if spin or others had any additional momentum on wasi websockets so far
Joel Dice (Oct 16 2024 at 19:54):Yeah, the SIP was merged, but no momentum since then. I haven't been able to link it to a business opportunity or strategic objective yet, so haven't been able to justify working on a prototype or a WASI standard proposal. I'd love to see someone pick that up if they're motivated.
Brooks Townsend (Oct 16 2024 at 20:10):Speaking from wasmCloud, we're essentially in the same boat that Websockets came up as a neat use case, but didn't result in a direct need for someone on the open source side / business side
Last updated: Nov 22 2024 at 16:03 UTC