Re: Value of Server-Sent Events

On Fri, Oct 23, 2009 at 6:24 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

True. I still feel that until I hear more requests for this from
authors I'm reluctant to add this feature to Gecko. See below

> - 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).

I think a decent JS library around XHR could get around most of these issues.

> - 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.

The gecko patch for this is 146kB[1]. Granted, that includes a fair
amount of tests. I haven't reviewed the patch so I don't know if it
could be made simpler, but I doubt that a significant portion of it
could be removed.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=338583#c126

/ Jonas

Received on Saturday, 24 October 2009 02:17:21 UTC