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
