WebSockets RFC is now official
ietf.org
ietf.org
WSGI doesn't support it (http://librelist.com/browser//flask/2010/9/1/flask-and-webso...). gevent is an option (http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets...), but would something like Mongrel2 be better (http://mongrel2.org/)?
UPDATE: There's also Juggernaut (http://flask.pocoo.org/snippets/80/), which uses node.js under the hood.
Twisted gives you the foundation for pretty amazing things to start with, and txWS does a good job of adding WebSockets.
Disclaimer: I work for Pusher.
We use it successfully at SiteSupport (http://sitesupport.com)
My use case involves sending model data to display in WebGL. Sending it any other way would be inefficient.
The step towards standardization will make this type of cross "platform" compatibility easier in the long run.
More important than which browsers support the API is which underlying protocol version the sockets speak. A lot of major browsers support the API but very few speak the same protocol.
I believe today's announcement is a finalized protocol standard which means that there's finally going to be a lingua franca for websockets.
* Mojolicious web framework which managed to keep up with the constantly moving standard! - http://mojolicio.us/
* PocketIO which is a Perl implementation of SocketIO - https://github.com/vti/pocketio
* Protocol::WebSocket module which adds WebSockets to the PSGI (Plack) stack - https://metacpan.org/module/Protocol::WebSocket
They introduced plenty of other crazy things.. but at least it works with proxies.
At least with hixie-76, connections would fail to connect if the intermediate proxies are not understanding WebSockets. Now, your connection will succeed, both client and server will believe they can successfully communicate, but communication will not work and die a slow timeout. Not very reliable, is it ?
* try websocket
* on failure, fallback to comet
WebSockets works best over SSL.
instead of the plain-text one: http://www.rfc-editor.org/rfc/rfc6455.txt
Well kind of. Last summer I did a road trip to newfoundland (canada) with a laptop, a gps and a webcam onboard [1]. The idea was to have people (friends and family) to follow our trip through a website to which I pushed webcam frames and gps coordinate in real time using websocket (socket.io) over my smarthphone. It was fun!
[1]: http://blog.rassemblr.com/2011/07/how-to-hack-a-road-trip-wi...
Publication as an RFC doesn't signify any status of the protocol standards-wise, almost any protocol can be documented in an informational, experimental or historical RFC.
Since all we get is TCP right now though, you can take advantage of that at least and easily do things like send deltas instead of absolute positions, and even things that depend on reliable order of transmission (which you can't rely on if it were UDP), in order to reduce bandwidth use.
If people really wanted to send data over this weird semi-HTTP websocket protocol then someone could have implemented it as a js library on top of proper socket calls.
I'm guessing the main issue was cross-domain security, but I would have liked to see this solved using some sort of policy file that can be requested from the domain before connecting, like Flash does.