HN Explorer

12 comments

[ 0.16 ms ] story [ 76.9 ms ] thread
neoveller
Is anyone else kind of baffled by the comment about the political risks of web sockets? Why do people waste time with answers like that?
camwest
Hi Neoveller,

I gave the talk and I agree the political risks comment was misplaced. I didn't think it was worth it to shut the person down though as it's my personal philosophy never to embarrass anyone if possible.

I hope you found the others parts of the talk more useful.

MostAwesomeDude
I can't watch the slides, but I wonder if they spend any time discussing how WebSockets don't offer any client security beyond raw TCP sockets.
palish
Why would WebSockets offer any client security beyond raw TCP sockets?
MostAwesomeDude
It was one of the original promises of WS and the reason that browsers offer it to client-side JS.
camwest
There are some people building on top of WebSockets with an eye towards security. Check out http://pusher.com/ for example, they designed system to account for 100% untrusted client.
pornel
For non-games usually Server-Sent Events (http://dev.w3.org/html5/eventsource/) may be simpler to use:

• it's pure HTTP, message format is dead simple ("data: payload\n\n")

• browser handles network failures and reconnections automatically.

• browsers can share same stream URL between windows

His use-cases with to-do app and analytics were good fits for SSE.

zeroxsys
I'll check that out, thanks!
camwest
Once Firefox supports SSE I agree that it would be easier to implement in many use cases. Although it doesn't have the same sort of fallback mechanisms available to it that WebSockets have (ActionScript sockets).

Here is some additional information about it that I found at stackoverflow: http://stackoverflow.com/questions/5195452/websockets-vs-ser...

pornel
You can fall back to XHR with long polling — the stream is trivial to parse.