cocoa-websocket

Cocoa-websocket doesn't seem to support the latest standard[1]. You can tell because the handshake has key1 and key2 which is protocol 00[2] Re: socket.IO, I haven't actually used it, so correct me if my assumptions are wrong, but the objc client doesn't seem to use WebSockets as a transport. So I imagine you can get the same bidirectional semantics if by using socket.IO-objc if you want to limit yourself to servers written in node (or have a socket.IO bridge). However, why not go with standards? Since socket.IO supports websockets, the objc implementation could be backed by SocketRocket easily. My two biggest complaints against Unitt & cocoa-websocket aside from them not supporting RFC6455 is having CocoaAsyncSocket as a dependency. I've dug deep into it's implementation, and even had a prototype of SocketRocket that used it (basicall

So, following up on the link in another comment on this article [1] to socket.IO-objc [2], one goes through a few forks of cocoa-websocket [3,4,5] to arrive at zimt [6]. Are there reasons to use SocketRocket over these other libraries (either socket.IO-objc, or the various forked lineage of cocoa-websocket/zimt)? (Also, to ask the question I always have to ask: is there a reason for a new library rather than contributing to one of the existing ones, possibly even helping Unitt support RFC6455?) [1] http://news.ycombinator.com/item?id=3563527 [2] https://github.com/pkyeck/socket.IO-objc [3] https://github.com/samlown/cocoa-websocket [4] https://github.com/adamjernst/cocoa-websocket [5] https://github.com/erichocean/cocoa-websocket [6] https://github.com/esad/zimt