Use server-sent events for notifying changes to browser

[Jermolene]

Server-sent events is a browser-based JavaScript interface to what used to be called long-polling. It allows a stream of real-time messages to be sent from the server to the browser. Support under Node.js is straightforward: http://cjihrig.com/blog/server-sent-events-in-node-js/

See http://caniuse.com/#feat=eventsource for browser support. The lack of support on IE means that we'll need to fall-back to the existing HTTP polling.

It is proposed to extend tiddlywebadaptor.js and server.js to support SSE so that the server automatically notifies the client about modified tiddlers that it doesn't already know about.

[pmario]

I'd vote for web sockets http://caniuse.com/#feat=websockets and socket.io on the server side http://socket.io/

[Jermolene]

Why do you vote for web sockets? SSE are a lot simpler, and I think less brittle.

See:

http://stackoverflow.com/a/5326159/3111487

http://www.html5rocks.com/en/tutorials/eventsource/basics/ (section headed "Server-Sent Events vs. WebSockets")

The clincher is that we simply don't need the full duplex chattiness of websockets; we've already got an api for the browser to request stuff from the server. We only actually need the real-time notifications. Given that, using SSE means that we don't add any dependencies under Node.js (and the article above suggests that we can polyfill IE10+).

[Arlen22]

If we are going to go with websockets I would definitely choose the ws npm package over socket.io. It is a fairly simple library and works well. I have also read reviews that say it is better than socket.io in some ways.

[xcazin]

The fact that SSEs are sent over traditional HTTP is a big advantage to me. It would makes Apache or Nginx proxies (for enabling HTTPS for instance) a lot easier to configure. Saying that after having spent several hours setting up an SSL proxy above a websocket-enabled nodejs server, to no success :-(

[Arlen22]

Does TLS support it better than SSL? I thought the TLS applied to the connection rather than the request, meaning that a reverse proxy should just forward the connection, I would have thought.

[NicolasPetton]

@Jermolene any news about this one? If nothing has been done yet, I'd be willing to implement SSE support & send a PR.

[Jermolene]

Hi @NicolasPetton we have a PR that is yet to be merged #4609. Hopefully we'll get it into the next version after v5.1.23.

[NicolasPetton]

Thanks @Jermolene.

@Arlen22 I've some more changes to your and opened a new one here #5279. I hope you don't mind.

[Arlen22]

I was adding in some additional changes and features, and then Jermolene pointed out that if we put this in now we are going to have to retain backward compatibility into the future, and so we all collectively decided to turn this into a third-party plugin. I'm going to host it on the twcloud account for now.

[Jermolene]

I was adding in some additional changes and features, and then Jermolene pointed out that if we put this in now we are going to have to retain backward compatibility into the future, and so we all collectively decided to turn this into a third-party plugin. I'm going to host it on the twcloud account for now.

Thanks @Arlen22, I'm excited to see where this goes. Just to add a link to the conversation over at #5853 that prompted this decision.

[pmario]

The relevant GitHub repo for the 3rd party plugin is https://github.com/twcloud/tiddlyweb-sse and the PR was: Improvements to SSE #5853

[Jermolene]

Thanks @pmario