3 ms·

Isn't this basically what we did some 10 years ago with a hidden, slowly loading iframe? It was widely known and used then, I suppose the technique became less

Isn't this basically what we did some 10 years ago with a hidden, slowly loading iframe? It was widely known and used then, I suppose the technique became less important and forgotten with AJAX arrival and is now being rediscovered. The only problem with this is c10k - you have to have something writing to the socket and this "something" was basically a process in most cases. It's a great fit for async things like Node or Twisted/Tornado, though. And for Erlang.

skue 13y ago
Yes, the umbrella term for this HTTP server push is Comet[1], and it's been around in various forms for years. But standardizing this in the form of server-sent events is a very Good Thing, especially with support baked into modern browsers. Also, unlike WebSockets it's also easy to add SSE support for mobile clients. I've implemented a SSE client class in just over 100 lines of Java, and it's similarly easy to do this with NSURLConnection/NSURLSession on iOS. The W3 standard provides an implementation section that reads like pseudocode.[2] [1]: https://en.wikipedia.org/wiki/Comet_%28programming%29 https://en.wikipedia.org/wiki/Comet_%28programming%29 [2]: http://dev.w3.org/html5/eventsource/#event-stream-interpretation http://dev.w3.org/html5/eventsource/#event-stream-interpreta...
pornel 13y ago
On the HTTP level it's quite similar to slow-loading iframes (although with less overhead on the wire), but the interface and usability are better. The browser will try hard to keep the connection always on for you (unless instructed otherwise). You don't have to implement your own logic for offline/online detection, exponential backoff, etc. Thanks to id:/Last-Event-Id header the server can make error recovery transparent to the client. You do need node/tornado/etc to take full advantage of it, but if all you have is PHP or such, then you can still make it real-time-ish. Because SSE automatically reconnects you can have any behavior ranging from a single persistent TCP/IP connection, through Comet, to regular polling. You control this with the `retry:` line and by (not) closing connection on the server (e.g. keep persistent connection when load on the server is low, set high `retry:` and close the connection when the load is high).

skue 13y ago

Yes, the umbrella term for this HTTP server push is Comet[1], and it's been around in various forms for years. But standardizing this in the form of server-sent events is a very Good Thing, especially with support baked into modern browsers. Also, unlike WebSockets it's also easy to add SSE support for mobile clients. I've implemented a SSE client class in just over 100 lines of Java, and it's similarly easy to do this with NSURLConnection/NSURLSession on iOS. The W3 standard provides an implementation section that reads like pseudocode.[2] [1]: https://en.wikipedia.org/wiki/Comet_%28programming%29 https://en.wikipedia.org/wiki/Comet_%28programming%29 [2]: http://dev.w3.org/html5/eventsource/#event-stream-interpretation http://dev.w3.org/html5/eventsource/#event-stream-interpreta...

pornel 13y ago

On the HTTP level it's quite similar to slow-loading iframes (although with less overhead on the wire), but the interface and usability are better. The browser will try hard to keep the connection always on for you (unless instructed otherwise). You don't have to implement your own logic for offline/online detection, exponential backoff, etc. Thanks to id:/Last-Event-Id header the server can make error recovery transparent to the client. You do need node/tornado/etc to take full advantage of it, but if all you have is PHP or such, then you can still make it real-time-ish. Because SSE automatically reconnects you can have any behavior ranging from a single persistent TCP/IP connection, through Comet, to regular polling. You control this with the `retry:` line and by (not) closing connection on the server (e.g. keep persistent connection when load on the server is low, set high `retry:` and close the connection when the load is high).