On Sat, Oct 24, 2009 at 9:37 PM, Ian Hickson <i...@hixie.ch> wrote: > On Sat, 24 Oct 2009, Michael Nordman wrote: > > On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson <i...@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. >
I'm not sure this would really need a notion of "critial" messages. That may just be complicating things unnecessarily. If an application is sending data with those kind of characteristics, it could be handled at the application level. It can send a "keyFrame" bit of its own and drop non key frames on the client side until it comes across the first key it observes. > a way for the server to opt-in to a system whereby people can join > in half-way and only get new messages Here's the mechanism for that purpose i was hinting at... I don't know what the current content type is defined for event streams, but suppose its... Content-Type: application/event-stream // the one defined for non-shareable streams Content-Type: application/event-stream-shareable A shareable stream cannot have "critical" messages (as far as the user-agent knows). The user agent, and any network appliances between the origin-server and that user-agent, need not buffer anything. ---------- Perhaps some scoping of how widely "shareable" a stream is could make sense... // the one defined for non-shareable streams Content-Type: application/event-stream // can be shared by everyone (network appliances could mux these streams) Content-Type: application/event-stream-universally-shareable // can only be shared within a particular session Content-Type: application/event-stream-session-shareable The latter could be useful for event-streams that contain data specific to a particular authenticated user. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
