That aside, it seems a bit ridiculous, given that we already have sockets, to bolt on a protocol that exists almost solely to work around security issues involved in a browser opening a socket.
If you want bidirectional communication to your app, it's much easier to make a server that uses the WebSocket Protocol (tornado, etc.) instead of rolling your own server and protocol.
Square has done a lot for iOS open source, with their unit test framework and other libraries and now this.
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
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 (basically went from CocoaAsync to dispatch_io to CFStream), and I'm not too impressed. Also, CocoAsync 2x or 3x more code than the entire WebSocket implementation without it. It also has drastically different codepaths for iOS and Cocoa and it's very difficult to see what's going on. Makes testing more difficult.
The other reason I decided to roll my own is just a learning experience. At first I wanted an excuse to play with new libdispatch io stuff[3].
[1] https://github.com/samlown/cocoa-websocket/blob/master/WebSo...
[2] http://en.wikipedia.org/wiki/WebSocket#draft-ietf-hybi-thewe...
[3] http://www.opensource.apple.com/source/libdispatch/libdispat...
http://code.google.com/p/unitt/wiki/UnittWebSocketClient
It has worked well so far, but I'm glad to see more activity in this area.
tools.ietf.org/html/rfc6455
Tornado is nice since it implements some of the legacy versions of WebSockets, but there are many servers that will probably deprecate them sooner rather than later.
Perhaps libPusher can just start using SocketRocket as a dependency and wrap it in Pusher-specific goodness...
If you have any questions, feel free to email me.
