- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 23 Oct 2009 18:24:22 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
On Oct 23, 2009, at 5:50 PM, Jonas Sicking wrote: > 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. Fair point, XHR could be extended to provide the needed functional advantages. But consider: - Now we're not comparing EventSource vs XHR + progress events, but EventSource vs XHR + two new as yet undesigned features. EventSource is spec'd, reviewed, multiply implemented and ready to go. - Using this approach with future XHR features will still be quite a bit less convenient, since you have to parse the message stream yourself, and may need to save multiple data chunks to do it right. - Using streaming XHR for long get could be error-prone; authors might falsely assume that messages will never be split across data chunk boundaries, and that might even be true in testing, but not for users on unusual network setups. (I'm not sure if this is a problem that "COMET" libraries have today). - EventSource is not a very big implementation burden - the WebKit patch to add it was a couple dozen lines, which were mostly the event stream parsing code. So it's not too terrible if we have it, and XHR in the future can do similar things in a slightly less convenient way. Regards, Maciej
Received on Saturday, 24 October 2009 01:24:58 UTC