The throttledConnection param is useful for helping to get around browser connection limitations. If the user opens a bunch of tabs, these long standing connections can hit the per-host connection limit, breaking navigation until the connection times out. The throttle option sets a long retry period and polls instead of waits. This sucks, but sucks less than your whole site hanging because the browser is queuing your connections!
And in your app, as events happen, use in D: auto stream = new UpdateStream(channel); stream.sendMessage(type, message);
and the helper app will push it all out. You might want to wrap some of this in try/catch since if the helper app dies, this will throw since it can't connect.
I found using user names as channels is good stuff. Then your JS doesn't provide a channel at all - your helper app gives it through the channel prefix argument.
OBSOLETE: This provides a kind of real time updates that can be consumed by javascript (and probably other things eventually). Superseded by new functionality built into arsd.cgi.
First, you compile the server app. dmd -version=standalone_rtud -version=rtud_daemon
Run it. It's pretty generic; probably don't have to modify it but you always can. It's useful to have a long running process anyway.
But then you'll want an intermediary between this and the javascript. Use the handleListenerGateway() function in your cgi app for that. You can pass it a channel prefix for things like user ids.
In your javascript, use EventListener("path to gateway"); And addEventListener(type, function, false);
Note: this javascript does not work in all browsers, but real time updates should really be optional anyway.
I might add a traditional ajax fallback but still, it's all js so be sure it's non-essential if possible.