Re: Value of Server-Sent Events

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).
>
> - Dealing with message boundaries instead of packet boundaries (or
> arbitrary batching-within-the-network-layer boundaries) is way more
> convenient and likely more efficient to a degree that I think goes beyond
> mere syntactic sugar.
>
> Regards,
> Maciej
>
>
I buy all of those advantages. This feature is a nice formalization of the
commonly used "hanging GET" found in many ajax applications.

An area that may be worth exploring, that would add to the list things that
go beyond syntactic sugar, could be for multiple documents to listen in on
the same event-stream backed by the same connection to the server. This
could reduce the total number of hanging GET style connections used by an
application (spread across multiple pages / workers) on a particular client,
and by extension the number of connections seen by the server-side.