... | ... | @@ -58,6 +58,20 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
* **2.3.7** `foreign` and `completed` changes are applied by `Feed` prior to any `local` changes or access.
|
|
|
|
|
|
### 3. Receiving Frames
|
|
|
#### 3.1 General Rules
|
|
|
* **3.1.1** Receive state storage for `persistent` data is separate from send state.
|
|
|
|
|
|
#### 3.2 Receiving Protocol
|
|
|
* **3.2.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
|
|
|
* **3.2.2** Received changes are marked as changes in the corresponding `Frame`.
|
|
|
* **3.2.3** Changes received flagged as `foreign` transition to `completed` in the `Frame`.
|
|
|
* **3.2.4** Changes received without `foreign` transition to `foreign` in the `Frame`.
|
|
|
* **3.2.5** A `Frame` is dispatched once all changes are believed to have been received.
|
|
|
* **3.2.6** A dispatched `Frame` is marked as `flushed`.
|
|
|
* **3.2.7** A dispatched and `flushed` `Frame` has its changes copied to persistent receive state for channels marked with a `persistent` storage type.
|
|
|
|
|
|
#### 3.3 Change Events
|
|
|
* **3.3.1** Change events occur on any kind of received change (foreign forwards or not)
|
|
|
|
|
|
### 4. Transmitting Frames
|
|
|
|
... | ... | |