On Oct 23, 2009, at 5:50 PM, Jonas Sicking wrote:
On Fri, Oct 23, 2009 at 3:21 PM, Maciej Stachowiak <m...@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
