... | ... | @@ -31,8 +31,15 @@ Are states or change lists timestamped? Seems unreliable as a way to stay synced |
|
|
|
|
|
Hence the following is true:
|
|
|
* Need a flags property to mark changes as *foreign* upon receipt (if not already foreign).
|
|
|
* Changes received already marked as *foreign* are fixed as non-changes (not to be forwarded)
|
|
|
* Receive state must maintain list of *foreign* changes, moved to new frames.
|
|
|
* Changes received already marked as *foreign* are fixed (not to be forwarded), but still marked as changes in the received frame. They can be flagged as *completed*.
|
|
|
* Receive state must maintain list of *foreign* changes, moved to new frames for forwarding.
|
|
|
* Received *foreign* changes become fixed once new frame constructed that takes those changes
|
|
|
* a local change to a *foreign* change removes the *foreign* flag
|
|
|
|
|
|
**Question: What about change callbacks?** Are these only for received changes or can they also be on sent changes? If on received, are they also on forwarded received changes? Change events ought to be with respect to received state, regardless of if forwarded or not. This is to allow for the proper handling and interpretation of received frames where status changes are vital to know, whereas sent changes are implicitly already known locally. Another handler could be provided for `onFlushed` in addition to `onChanged`.
|
|
|
|
|
|
Hence the following is true:
|
|
|
* Change events occur on any kind of received change (foreign forwards or not)
|
|
|
* Flush events occur when a change is flushed into the stream, and always before a change event occurs.
|
|
|
* Change events should occur before a frame callback occurs for received frames
|
|
|
|