Something else that might be worth looking into are server-sent DOM
events. They've not yet landed in Firefox (slated for Firefox 7), but I
believe they're available in other browsers. There's lots of good
information in the tracking bug for their Mozilla implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=338583 . Of course, you
could do some rather nasty hackish things with Java, Flash, or
Silverlight, but I think that Sandy's suggestion of a long-lived XHR is
your best bet.
--
Barry van Oudtshoorn
www.barryvan.com.au
Not sent from my Apple ?Phone.
On 02/06/11 05:24, Philip Thompson wrote:
Thanks. That is some good information. I was unaware of "long
polling"/comet. That does seem like it would be a good solution. Also,
I'll be controlling what browser they'll be using, so that shouldn't
be an issue.
I've also done a little bit of reading on web sockets, but I think it
may be a little bit early to implement that in a production system at
this point. I'm anxious to see how that picks up and where it will be
going.
Any other thoughts on how to do "live" updating?
Thanks!
~Philip
On Wed, Jun 1, 2011 at 3:53 PM, Sanford Whiteman
<[email protected] <mailto:[email protected]>> wrote:
> 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
--
http://lonestarlightandsound.com/
