I've written a draft specification for the experimental Ring websocket protocols that are in testing in 1.11.0-alpha1. I'd appreciate any feedback people want to give. https://github.com/ring-clojure/ring/blob/master/SPEC-alpha.md
At work we already went down the WebSocket path with the sunng adapter (because we wanted to be on Jetty 11). I'll take a look on Monday and see how far that is away from your new spec. One big difference that jumps out at me: your listener is a protocol with fewer handler endpoints, compared to a hash map with more keys to functions for the handlers.
You mean like instead of send-text and send-binary, there's just a single send?
Yeah, and sunng has both ping and pong...
On my phone so typing is limited:grin:
No problem! I didn't include on-ping because the Jakarta websocket library doesn't include that. Also because on-ping would require calling ping on the socket, so the server should already know when its sending a ping.
I decided on a polymorphic send rather than separate send-text and send-binary functions as it allows for higher-level data structures to potentially be sent, and a binary or text representation chosen as appropriate.
It's also worth mentioning that I implement the Listener protocol for maps, so you can use a map of functions.
I also very much appreciate you taking a look.
I didn't look at the implementation yet (coz phone) but good to know a map can be a listener, nice.
Apologies for the late response. Currently you can check headers on the upgrade request, but can't add headers to the response, so extensions and subprotocols aren't supported as of 1.11.0-alpha2
FWIW, we're in the process of updating to sunng 0.30.0 and Jetty 12.0.1 but I will keep an eye on the O.G. Ring adapter since you generally take a much more conservative approach to updates, and we've run into a few edge case breakages from time to time with the sunng adapter.
Once the websocket spec for Ring is finalised, my plan is to submit patches to other adapters, including the "jetty9" adapter to see if they'll support the format. My hope is to get a standard interface for websockets.
Do you have support for WebSocket protocols and extensions? (coming from WS upgrade request)
(that seems to be the only thing we rely on beyond text, close, and error right now -- we don't even pay attention to open/connect since we only care about authenticated sessions, which means sending a token via text).