Draft 13 support about websocket-node HOT 11 CLOSED

My intentions have so far been to support one and only one draft of the protocol - whichever one is newest. I intend to update the server to support protocol version 13 instead of 8 soon, but I've not had the bandwidth to tackle it yet. If you'd like to make the necessary changes on a branch that I can pull from that would be awesome. I may consider temporarily supporting multiple versions until we reach stability on the final release version at this point since it seems more people are starting to use this library for communicating with browser clients (my client is written in Flash and maintained by me, so I haven't had to deal with cross-browser issues, and can update it at will)

Supporting multiple versions would involve duplicating most of the classes, one set for version 8 and another for version 13, and modifying the WebSocketRequest class to detect the protocol version and instantiate the correct WebSocketConnection class for that connection accordingly.

This will add more complexity -- bugs will likely have to be fixed in two places -- and will delay the implementation of my planned streaming interface, since I don't want to write a new streaming API once for each protocol version.

Thoughts? Alternative multi-version support strategy ideas?

from websocket-node.

Just to mention, version 13 has these two changes:

Change the origin header name: Sec-WebSocket-Origin -> Origin
Sec-WebSocket-Version header value: 8 -> 13

I think that's all that has changed.

If you want to have multiple version of your software with different version support, use branches. Name them after WS protocol version. Then they can be developed individually, and deleted/closed when a version gets obsolete. You can develop to each of them by working on a feature branch and merging it to all different version branches as well.

from websocket-node.

I think @kaisellgren's suggestion is a good one. I'll try to work out a branch that supports 13. For anyone who needs to support multiple protocols, I guess it's easy to use a different port and let the client connect to the right port based on the supported protocol.

from websocket-node.

While working on WebSocket support for webbit I came across the Autobahn test suite.

This is a fantastic test suite that allowed me to weed out a ton of bugs. I recommend you do the same!

from websocket-node.

Never mind - I just saw you already have it :-) Awesome!

from websocket-node.

@kaisellgren -- Those are really the only changes between version 8 and version 13? Wow. That's rather simple. Could handle that quite easily without much trouble. I'll double-check the spec.

from websocket-node.

@aslakhellesoy - the AutoBahn test results for WebSocket-Node are here: http://worlize.github.com/WebSocket-Node/test-report/servers/

from websocket-node.

@theturtle32: I don't remember if I just looked at the differences between 12 and 13, or 8 and 13, but yeah, regardless, the differences should not be too technical. You better check out too because I might have missed things. :)

from websocket-node.

I'd like to jump on the motion to upgrade to version 13 as soon as you can if possible. Thank you :)

from websocket-node.

Protocol Version 13 support is complete and is now released as version v0.0.20 on NPM.

from websocket-node.

Thanks Brian!

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Brian McKelvey [email protected] wrote:

Protocol Version 13 support is complete and is now release as version v0.0.20 on NPM.

Reply to this email directly or view it on GitHub:
#14 (comment)

from websocket-node.