> Is this a good way to manage these notifications? It's one of several reasonable options. Reviewing the others is a lot to get into here.
I would recommend you use the long-polling approach, where you leave the XHR open until there is an interesting update to send across the wire. In this case, you don't want to use .periodical() and link:chain, but rather reconnect the XHR onComplete with optional .delay(). I don't use link:chain unless independent parts of my application trigger the same XHR without any knowledge of each other (not uncommon, of course) and/or might change XHR parameters at send() time. That is, if you're setting off this XHR one time in your code, .periodical() and link:chain pretty much just mean you increase your overhead with a dangerous downside. Imagine if your server has a slowdown that causes XHRs to take 11 seconds to connect and return -- you're guaranteeing clients will build up a big backlog of XHRs and get only misery when fast service returns. (Yes, in proper operation when your benchmarks are < 1s, 10s seems like it'll be fine forever, but you have to look at reality....) HOWEVER, simplistic long-polling is doomed in IE 7 because of connection limits. The most sophisticated way to deal w/browser differences is with a Comet framework, where capable browsers get permanent, multi-result streaming connections of various sorts, most other browsers get single-result long polling connections using DNS and iframe hacks if necessary, and outliers get periodical checks. You could bluntly down-shift to periodical checks in IE 7 and FF 2 (if you care about the latter) and be largely okay. -- Sandy
