... | ... | @@ -63,23 +63,31 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
* **3.1.2** One instance of `Feed` *owns* a given `Frame` id, including across a network.
|
|
|
|
|
|
#### 3.2 General Protocol
|
|
|
* **3.2.2** Received changes are marked as changes in the corresponding `Frame`.
|
|
|
* **3.2.6** A dispatched `Frame` is marked as `flushed`.
|
|
|
* **3.2.1** Received changes are marked as changes in the corresponding `Frame`.
|
|
|
* **3.2.2** A dispatched `Frame` is marked as `flushed`.
|
|
|
|
|
|
#### 3.3 Owner Protocol
|
|
|
* **3.3.1** Received changes do not result in a dispatch event.
|
|
|
* **3.3.2** Received changes are applied to a new `Frame` upon a frame creation request to `Feed`.
|
|
|
* **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.7** A created `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type, before creation completes.
|
|
|
* **3.3.3** Changes received flagged as `foreign` transition to `completed` in the `Frame`.
|
|
|
* **3.3.4** Changes received without `foreign` transition to `foreign` in the `Frame`.
|
|
|
* **3.3.5** A created `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type, before creation completes.
|
|
|
|
|
|
#### 3.4 Non-Owner Protocol
|
|
|
* **3.2.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
|
|
|
* **3.2.5** A `Frame` is dispatched once all changes are believed to have been received.
|
|
|
* **3.2.7** A dispatched `Frame` has its changes copied to persistent 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)
|
|
|
* **3.4.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
|
|
|
* **3.4.2** A `Frame` is dispatched once all changes are believed to have been received.
|
|
|
* **3.4.3** A dispatched `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type.
|
|
|
* **3.4.4** `Frame` creation requests use state from most recent dispatch, excluding newly received changes that have not yet dispatched.
|
|
|
|
|
|
#### 3.5 Change Events
|
|
|
* **3.5.1** Change events occur on any kind of received change.
|
|
|
* **3.5.2** Change events are dispatched immediately prior to completed `Frame` dispatch for a non-owner.
|
|
|
* **3.5.3** Change events are dispatched immediately prior to creation of a `Frame` for an owner.
|
|
|
* **3.5.4** Change events may occur in parallel but will be completed before dispatch or creation.
|
|
|
* **3.5.5** One change event occurs per changed channel.
|
|
|
* **3.5.6** `aggregate` channels with multiple changes result in a single event.
|
|
|
* **3.5.7** `Frame` and channel number are provided to event handler.
|
|
|
* **3.5.8** The provided `Frame` has all state changes applied, as provided at dispatch or creation.
|
|
|
|
|
|
### 4. Transmitting Frames
|
|
|
|
... | ... | |