

Server-Sent Events - Isofarro
http://html5doctor.com/server-sent-events/

======
sambeau
OT: Where has this word Polyfill appeared from? I first read it yesterday and
here it is again.

~~~
chc
It's been in use for a while. In home repair, polyfills are used to fill in
gaps and level out uneven surfaces. The term was adopted by web developers to
refer to code that implements standard features in browsers that don't support
them yet.

------
luigi
The last section is really important. If you don't need the full duplex
communication of WebSockets, Server-Sent Events are a much better choice. If
you can get away with using AJAX to update the server from the client, do it.

------
Klonoar
A fun side note about these: they're supported on the Wii's version of Opera.
;)

I wrote a very basic Node.js server to do this, which could in theory work
well for 2-player games in the browser: <https://github.com/ryanmcgrath/wii-
js/blob/master/server.js>

------
thomaslee
I wrote a partial implementation (no event types or useful IDs) of the server-
side SSE protocol for kicks using nodejs (an old version of node, but it still
seems to work):

<http://github.com/shinetech/eventserver>

Basically you can post JSON messages via HTTP & they're streamed in real time
to clients via the Server-Sent Events protocol.

This is a great, simple protocol with a dead-simple client-side API -- I can
see it being really popular as browser support for SSE and CORS improves:
<http://www.w3.org/TR/cors/>

------
untog
This is very interesting- I am developing a webapp that allows you to track
other people's taxi journeys, and right now I'm AJAX polling every 30 seconds
becuase I figured WebSockets would be too intensive on a phone (open
connection = drained battery).

Does anyone know if this would also end up with an open connection the whole
time?

~~~
jiggy2011
I would imagine it is using stream sockets , so yes (unless it's really just
doing polling in the background).

What we really need is some way of doing UDP via javascript, this would enable
many things.

EDIT: Why would I want someone else able to track my taxi journey?

~~~
untog
With regard to your edit: so that they know where you are, essentially.
There's a social aspect ("when are you getting to the bar?") as well as a
safety one (travelling late at night, someone will always know where you are).

There's also some interesting benefits from my POV- it's effectively returning
live data on the average mph on every street in the city. Relies on getting a
decent number of users before being useful of course, but still.

Gratuitous plug for the site with more info: <http://www.taxono.my/>

~~~
gtaylor
Wouldn't Google Latitude do this, already?

~~~
untog
To an extent, yes. But my app also sends over details like where the person is
going to, which AFAIK Latitude doesn't do.

The app also lets you search for destinations, gives you a time and fare
estimate, split the total between friends, review your cab ride... while the
tracking stuff is a central feature, it isn't the only one.

------
dylanvee
James Coglan's Faye project (<https://github.com/faye>) contains some nice
implementations of Server-Sent Events for Ruby and Node.

------
geuis
I just don't get how this is any better than web sockets, especially using a
library like Socket.io.

I get the option of 1-way or 2-way communication built in. I don't have to
worry about reconnects. It falls back all the way to IE5.5. It's usable in a
number of languages and frameworks including node.js and Python.

What are the benefits of yet another framework?

~~~
LeafStorm
First, you seem to be confusing WebSockets, which is a protocol and low-level
DOM interface for dealing with that protocol with Socket.io, which is a
software framework for client-to-server messaging that uses WebSockets as one
possible transport. (And pretty much has to take over your server entirely in
order to work.) It's like reading an article about Rack and saying, "I don't
see how this is any better than Ruby on Rails."

Now that that's out of the way: Strictly speaking, WebSockets are "better"
than SSE in that you can do everything you can do with SSE using WebSockets.
However, the SSE protocol:

* Is plain HTTP, instead of adding on a separate protocol,

* Has an easy-to-generate text-based format,

* Does not require major upgrades to your server, and

* Can be emulated on non-conforming browsers using standard XHR's.

So when all you _need_ to do in realtime is send data from the server to the
client (remember, you can still use XHR's to call back to your server), SSE is
far easier to implement both on the client and on the server.

