W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Value of Server-Sent Events

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 23 Oct 2009 18:24:22 -0700
Cc: Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
Message-id: <D2479C61-6065-41A7-A359-CB389AC4174B@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

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.

Received on Saturday, 24 October 2009 01:24:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC