- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 23 Oct 2009 17:50:26 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
On Fri, Oct 23, 2009 at 3:21 PM, Maciej Stachowiak <mjs@apple.com> wrote: > On Oct 23, 2009, at 1:44 PM, Jonas Sicking wrote: > >> >> I also continue to miss actual developer demand for server sent >> events. Seems like it doesn't add a lot of sugar over simply using >> XMLHttpRequest and progress events. But again, I'm fine with >> publishing a new WD. > > Besides syntactic sugar, here are some advantages over using XHR and > progress events (or readystatechange events, which some client-side JS > libraries use today): > > - Does not force the full event stream to be stored in memory until the > connection is closed (XHR's responseText effectively forces this). This is > the biggest one. A long event stream shouldn't take progressively more > memory. > > - Does not force you to reparse the event stream each time new data comes in > (XHR + progress events doesn't have an easy way to get just the new data > chunk). Actually, support for these two things I think we need to add to XHR. We got the same request for file reads recently. I suspect it could be done by setting some "streaming mode" flag on the XHR before send()ing the request, and then delivering data through either a new event, or through existing "progress" events. / Jonas
Received on Saturday, 24 October 2009 00:51:20 UTC