> We did some testing here, and things mostly seem to be working,
> but there is some flakiness. Not sure why as it's not consistent,
> but we had two machines with Firefox (taking to LAMP server) just
> fail to update altogether (panes in chat window go blank),
> whereas some machines tocked along fine.
Thanks for trying it! Can't repro here, but will try again later today getting more people involved.
> That one sounds risky, leave it for 1.7 I think.
Ok -- lucky I read this message right now, I was _just_ going to commit it! Anyway, I think it's pretty safe as it retains the standard chat approach. There's a small change in index.php to use jsupdated.php instead of jsupdate.php if the user has selected the "stream" option.
Here's the patch for review (and for testing -- hey Julian!):
http://git.catalyst.net.nz/gitweb?p=moodle.git;a=log;h=streamchat
To
download a patch you can apply with "patch":
http://git.catalyst.net.nz/gitweb?p=moodle.git;a=commitdiff_plain;h=3aef5142506cf2f95ea05b868b60dc4e83101539;hp=f639aceb20af4296f9c96b16eef4d6f626e40c40
And here's the description of what it does, and how it does it...
> mod/chat: Normal method - introducing "Stream" updates.
>
> This is an alternative version of jsupdate.php that acts
> as a long-running daemon. It will feed/stall/feed JS updates
> to the client. From the module configuration select "Stream"
> updates.
>
> The client connection is not forever though. Once we reach
> CHAT_MAX_CLIENT_UPDATES (currently 1000), it will force
> the client to re-fetch it.
>
> This buys us all the benefits that chatd has, minus the setup,
> as we are using apache to do the daemon handling.
>
> Chat still defaults to the normal update method, which is now
> optimised to take advantage of keepalives -- so this change is
> safe. The instructions in the config page also indicate that this
> mode may not be well supported everywhere. It hasn't been
> tested on IIS for starters.
>
> In terms of relative cost -- if each hit on jsupdate.php incurs
> on ~20 db queries and delivers one update to the client, each hit
> on jsupdate takes ~20 queries, and then roughly 2~3 queries to
> serve each of the next 1000 updates. On busy sites, the difference
> is huge.
>
> There is still room for enhancements in both keepalive and stream
> update methods. I am pretty sure we can trim DB queries more.