[rvanmil]

Or, if you’re building for clients with a traditional “enterprise” and “secure” IT infrastructure: add refresh buttons and call it a day. If there’s one thing in my experience that consistently fails in these environments and cannot be fixed due to endless red tape, it’s trying to make real-time work for these type of clients.

[palmfacehn]

Jetty/CometD will fall back to long polling if other transports are not available.

[cbsmith]

Honestly, all the techniques for this stuff have their problems, including the refresh button.

[rvanmil]

True, though when carefully implemented it’s the most reliable option I guess.

[cbsmith]

I've switched to using SSE to get around problems with the refresh button. It's pretty simple and reliable.

[rvanmil]

That’s great. Unfortunately I’ve seen SSE fail quite a few times in the scenario I described.

[chgs]

My browser has a refresh button. Alas your application likely breaks when I use it.

[WuxiFingerHold]

In this threads context of sending specific application data from the server, I don't think this will happen.

[rvanmil]

Not entirely sure why it would break…?

[chgs]

Clearly I don’t know what your application is, but many heavyweight “web apps” don’t cope with a simple refresh, kicking back to a default screen or even login screen in some cases.

[wruza]

Also some apps ignore simple refresh and only react to hard refresh (ctrl-f5 and alikes). Refresh is as unreliable as other methods from user pov.

[hobobaggins]

Sometimes this is to scope logins to single tabs for security reasons (I think that's why Userify does it that way). It's annoying but for infrequently used apps, no worse than getting logged out every three minutes.

[klysm]

client side state that isn't in the URL or local storage