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]> 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/

Reply via email to