streams should monitor for new comments in realtime

[scd]

It would be kind of cool if streams monitored for new comments in a similar fashion to discussions.

[brendanheywood]

yeah the discussions do this is a fairly horrid way, best way would be a push event based system based on websockets which should sit over the existing infrastructure we have in place for the app notifications. There is some good middle ware out there that handles most of this

[scd]

As I understand it we need browser client implementation and server gateway implementation. I have done some partial research to a level of depth that leads me to conclude that this issue will not be resolved for the streams release.

Gateway

Kaazing seems to be the standard HTML5 implementation and can be installed in Debian:

http://developer.kaazing.com/documentation/jms/3.5/about/setup-guide.html

Comet and Reverse AJAX seem to be other buzwords.

https://www.ibm.com/developerworks/library/wa-reverseajax2/

We should probably go with an HTML5 solution as it is not mission critical and our website will still work adequately if WebSockets is not supported by a browser.

I am guessing we can install the gateway on any cloud server, not necessarily directly on prod. Are there any cross domain issues?

Browser side implementation

There seem to be many jQuery plugins.

[brendanheywood]

Yeah this is a big architecture thing so need to do a lot of research. Happy to defer this for a couple releases

[brendanheywood]

My preference would be to go with pushpin which is perfect for retro fitting either long polling, websockets, or server push events onto existing legacy code bases which don't use an event architecture (ie apache + perl)

http://pushpin.org/

[brendanheywood]

Also fyi, comet is formally 'EventSource' or 'Server Push events' which is unidirectional server->client, and is more or less a dead spec even thought support is goodish:

http://caniuse.com/#feat=eventsource

WebSockets is bidirectional and a better spec and is better supported too:

http://caniuse.com/#search=websockets

Long polling has deep old support, and is a sane fall back for almost any legacy browser - the issues are all server side as things like apache are utterly stupid as their whole design is around short lived monolithic processes. But pushpin proxying apache solves this too.

So tl:dr, I think we aim for websockets purely as a progressive enhancement for those browsers that do support it, which is pretty well the ones we are currently supporting anyway. Ignoring long poll will make the code simpler.

[scd]

I agree On Sep 29, 2015 10:22 PM, "Brendan Heywood" notifications@github.com wrote:

Also fyi, comet is formally 'EventSource' or 'Server Push events' which is unidirectional server->client, and is more or less a dead spec even thought support is goodish:

http://caniuse.com/#feat=eventsource

WebSockets is bidirectional and a better spec and is better supported too:

http://caniuse.com/#search=websockets

Long polling has deep old support, and is a sane fall back for almost any legacy browser - the issues are all server side as things like apache are utterly stupid as their whole design is around short lived monolithic processes. But pushpin proxying apache solves this too.

So tl:dr, I think we aim for websockets purely as a progressive enhancement for those browsers that do support it, which is pretty well the ones we are currently supporting anyway. Ignoring long poll will make the code simpler.

— Reply to this email directly or view it on GitHub https://github.com/theCrag/website/issues/2026#issuecomment-144043565.

[scd]

This will not be done until we have a major rework of our javascript and a websocket implementation. Closing for now.