Re: Value of Server-Sent Events

On Oct 26, 2009, at 7:07 PM, Ian Hickson wrote:

> On Sun, 25 Oct 2009, Michael Nordman wrote:
>>
>> 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.
>
> Maybe. I was expecting some systems to send a single "keyframe" as the
> first event, which would be important for the interpretation of the  
> rest,
> without ever repeating it.

I think a single keyframe that is valid independent of subsequent  
events is not very likely. A very likely kind of "keyframe" is to dump  
a full fresh state before sending change notifications, but it's not  
useful without all of the subsequent events. A keyframe that stays  
valid indefinitely regardless of subsequent events does not seem  
likely to me in any realistic scenario.

What seems more likely is sending periodic "keyframes" (with full  
state) and incremental "delta frames" in between - that would let the  
client support sharing by dropping everything *before* the most recent  
keyframe but resending every event starting with the most recent  
keyframe, on the assumption that they are deltas relative to the  
keyframe.  That would match the analogy of keyframes in video  
compression, and would likely work for use cases where the client is  
staying in sync with a remote state.

> But either way, we can figure this out when we get to it; we'll need
> implementation experience to know what people really want from this.

I'm curious if there's any use case for where there are no critical  
events or "keyframes".

Regards,
Maciej

Received on Tuesday, 27 October 2009 03:06:03 UTC