Re: Value of Server-Sent Events

On Oct 24, 2009, at 9:37 PM, Ian Hickson wrote:
>
> "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.

We could just let the client opt in, on the assumption that it might  
know there are no critical messages, or it might be able to get the  
relevant information in some other way.

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

That's an interesting idea. However...

It seems like a very likely kind of "critical message" scenario is  
where the first message tells you the current state of something, and  
subsequent messages are state changes. (It might not necessarily be  
the full state; the EventSource request may include a sequence number  
that identifies the client starting state and the server responds with  
a delta that updates to the latest server state, followed by further  
update events; or it could be the full initial state.) It seems like  
in this kind of scenario, every message is critical. The only way  
another client could share an EventSource in this case is if it  
already somehow knows the current state. This could be possible if the  
known latest state is maintained by a SharedWorker.

Some examples of where this model could apply: instant messaging where  
the full past history of the conversation is shown, live multi-user- 
editable document, shared calendar with updates of new events. It  
seems like these use cases can't easily be served by a shared  
EventSource.

A scenario where this consideration would not apply might be instant  
messaging where the prior history of the conversation is *not* shown -  
in that case it's ok to just show the messages starting from new ones.  
There may be other scenarios where you only care about new events and  
don't care about deltas relative to some known base state.

Regards,
Maciej