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

Re: Value of Server-Sent Events

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 23 Oct 2009 17:50:26 -0700
Message-ID: <63df84f0910231750r53a87c5evaf4ceed5dd5ff806@mail.gmail.com>
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

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