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