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

Re: Value of Server-Sent Events

From: Ian Hickson <ian@hixie.ch>
Date: Sun, 25 Oct 2009 04:37:13 +0000 (UTC)
To: Michael Nordman <michaeln@google.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Arthur Barstow <art.barstow@nokia.com>, public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0910250434170.13521@hixie.dreamhostps.com>
On Sat, 24 Oct 2009, Michael Nordman wrote:
> On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Fri, 23 Oct 2009, Michael Nordman wrote:
> > >
> > > 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.
> >
> > The spec technically allows this already, though as written it 
> > requires sending all the same messages again, so it's not really 
> > practical (and loses the "don't have to hang on to everything" 
> > advantage). It's not clear to me how we would know which messages are 
> > skippable -- maybe in v2 we can add a flag that indicates that this 
> > message block should be remembered, and another flag to indicate that 
> > all previous remembered messages should be dropped, or something like 
> > that, and when a new page hooks in, if the event source supports it, 
> > it would just get the saved messages and then resume with whatever the 
> > next message is.
> 
> > sending all the same messages again... flag that indicates... remembered

"sending all the same messages again" may have been a poor use of words. I 
meant that all the events already received by the browser on the existing 
connection would be (re)dispatched to the new EventSource object. I agree 
that's suboptimal; to get around that we'd need a way for the server to 
opt-in to a system whereby people can join in half-way and only get new 
messages. To do that, though, while still supporting the case of some 
messages being critical (e.g. a message saying how the rest of the 
messages are to be decompressed), we'd need a mechanism to indicate 
"critical" messages that are to be stored and dispatched to any new 
clients when a new EventSource object to that URL is created.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 25 October 2009 04:24:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT