Closed whawker closed 8 months ago
+1 for this. Also solves #152 @dmonad any chance you would consider merging this PR?
I made bad experiences with feature requests like this before. It's a valid concern. However, it adds a few features that blow up the codebase, that I need to maintain forever, and that are generally not needed by most users. I don't want y-websocket to blow up with things. Ultimately, the codebase would get too large for anyone to understand, modify, and adapt to their own needs.
There is just a plethora of things that people want to add to y-websocket. But I want y-websocket to be a barebone implementation that you can adapt to their own needs. If you are interested in a one-size-fits all solution there are other attempts: Check y-sweet, LiveBlocks, or Hocuspocus.
I also feel you could solve the issue differently by wrapping Websocket in a Base64 Layer and supplying it as a polyfill to y-websocket:
class Base64Websocket {
send (m) { super.send(toBase64(m)) }
set onmessage (f) {
super.onmessage = (m) => f(fromBase64(m))
}
}
new WebsocketProvider(.., { WebsocketPolyfill: Base64Websocket })
On AWS I am not able to use binary in WebSocket payloads, this PR adds two backwards compatible options
transformRead
andtransformWrite
to convert the incoming and outgoing data on the WebSocket.Example usage
Huly®: YJS-736