... | ... | @@ -58,39 +58,37 @@ 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 General Protocol
|
|
|
* **3.1.1** Non-owner receive state storage for `persistent` data is separate and different from send state as maintained by owners.
|
|
|
* **3.1.2** One instance of `Feed` *owns* a given `Frame` id, including across a network.
|
|
|
* **3.1.3** Timestamps of received changes must be less than or equal to the timestamp of subsequently created or dispatched `Frame`s to which they are applied.
|
|
|
* **3.1.4** Data channel storage mode is respected, meaning such changes can be overridden and lost for `persistent` and `transient` modes.
|
|
|
|
|
|
#### 3.2 General Protocol
|
|
|
* **3.2.1** Received changes are marked as changes in the corresponding `Frame` being formed.
|
|
|
* **3.2.2** A dispatched `Frame` is marked as `flushed`.
|
|
|
* **3.2.3** A created `Frame` is not 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.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.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 (`foreign` or not).
|
|
|
* **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.
|
|
|
* **3.1.5** Received changes are marked as changes in the corresponding `Frame` being formed.
|
|
|
* **3.1.6** A dispatched `Frame` is marked as `flushed`.
|
|
|
* **3.1.7** A created `Frame` is not marked as `flushed`.
|
|
|
|
|
|
#### 3.2 Owner Protocol
|
|
|
* **3.2.1** Received changes do not result in a dispatch event.
|
|
|
* **3.2.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.5** A created `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type, before creation completes.
|
|
|
|
|
|
#### 3.3 Non-Owner Protocol
|
|
|
* **3.3.1** Received changes accumulate into a waiting `Frame` with correct timestamp.
|
|
|
* **3.3.2** A `Frame` is dispatched once all changes are believed to have been received.
|
|
|
* **3.3.3** A dispatched `Frame` has its changes copied to persistent state for channels marked with a `persistent` storage type.
|
|
|
* **3.3.4** `Frame` creation requests use state from most recent dispatch, excluding newly received changes that have not yet dispatched.
|
|
|
|
|
|
#### 3.4 Change Events
|
|
|
* **3.4.1** Change events occur on any kind of received change (`foreign` or not).
|
|
|
* **3.4.2** Change events are dispatched immediately prior to completed `Frame` dispatch for a non-owner.
|
|
|
* **3.4.3** Change events are dispatched immediately prior to creation of a `Frame` for an owner.
|
|
|
* **3.4.4** Change events may occur in parallel but will be completed before dispatch or creation.
|
|
|
* **3.4.5** One change event occurs per changed channel.
|
|
|
* **3.4.6** `aggregate` channels with multiple changes result in a single event.
|
|
|
* **3.4.7** `Frame` and channel number are provided to event handler.
|
|
|
* **3.4.8** The provided `Frame` has all state changes applied, as provided at dispatch or creation.
|
|
|
|
|
|
### 4. Transmitting Frames
|
|
|
#### 4.1 General Protocol
|
... | ... | @@ -143,15 +141,24 @@ enum class StorageMode { |
|
|
};
|
|
|
```
|
|
|
|
|
|
### Change Status
|
|
|
### Change Type
|
|
|
```c++
|
|
|
enum class ChangeType {
|
|
|
UNCHANGED,
|
|
|
LOCAL,
|
|
|
FOREIGN,
|
|
|
COMPLETED
|
|
|
};
|
|
|
```
|
|
|
|
|
|
### Frame Store
|
|
|
Persistent data requires storage, as does transient and aggregate data. The same storage class can be used for both kinds, where persistent state can be maintained within a shared instance. One storage object can be merged into another as per the rules given in the requirements section. Each `Frame` has its own local and persistent storage object. It must contain the following elements:
|
|
|
|
|
|
* Channel data storage for arbitrary types.
|
|
|
* Record channel status.
|
|
|
* Record channel change type
|
|
|
* Keep list of change and flush event handlers for `Frame`.
|
|
|
|
|
|
## Discussion
|
|
|
Each frame is involved in a number of stages within the system, these are:
|
|
|
1. Formation
|
... | ... | |