... | ... | @@ -16,43 +16,53 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
* **1.2.1** A data channel can in principle be any type.
|
|
|
* **1.2.2** It should be possible to fix the type at runtime.
|
|
|
* **1.2.3** To change the type of a non-fixed channel, it must be recreated.
|
|
|
* **1.2.4** Data channels have a storage mode (persistent, non-persistent, recent).
|
|
|
* **1.2.5** Persistent data exists between frames, over time.
|
|
|
* **1.2.6** Non-persistent becomes discarded at the end of the frames lifetime.
|
|
|
* **1.2.7** Recent channels accumulate all changes since the last frame, and then discard.
|
|
|
* **1.2.8** Non-persistent channels only contain the most recent data.
|
|
|
* **1.2.4** Data channels have a storage mode (`persistent`, `transient`, `aggregate`).
|
|
|
* **1.2.5** `persistent` data exists between frames, over time.
|
|
|
* **1.2.6** `transient` data becomes discarded at the end of the frames lifetime.
|
|
|
* **1.2.7** `aggregate` channels record all changes since the last frame, but otherwise behave as `transient`.
|
|
|
* **1.2.8** `persistent` and `transient` channels only contain the most recent data item.
|
|
|
* **1.2.9** `transient` channels are always a list of items, possibly empty.
|
|
|
|
|
|
#### 1.3 Channel Mappings
|
|
|
* **1.3.1** Channels below 32 are fixed to `VideoFrame` type.
|
|
|
* **1.3.2** `VideoFrame` channels have a non-persistent storage status.
|
|
|
* **1.3.2** `VideoFrame` channels have a `transient` storage status.
|
|
|
* **1.3.3** Channels between 32 and 64 are fixed to `AudioFrame` type.
|
|
|
* **1.3.4** `AudioFrame` channels have an accumulate recent changes storage status.
|
|
|
* **1.3.4** `AudioFrame` channels have an `aggregate` storage status.
|
|
|
* **1.3.5** Channels between 64 and 4046 are of mixed but fixed types and are reserved.
|
|
|
* **1.3.6** Channels above 4096 have no fixed type and are not reserved.
|
|
|
|
|
|
|
|
|
### 2. Creating and Modifying
|
|
|
* **2.1** A `Feed` class must manage the creation of frames.
|
|
|
* **2.2** A `Frame` can be modified only prior to flushing (aka. transmission).
|
|
|
* **2.3** Modifications after flushing are discarded.
|
|
|
* **2.4** A `Frame` can only be flushed once.
|
|
|
* **2.5** Modifications prior to flushing are local to the frame only.
|
|
|
* **2.6** Frames are associated with a valid source identifier by `Feed`.
|
|
|
* **2.7** `Frame` id and timestamp together are unique within the `Feed`.
|
|
|
* **2.8** Modifications are one of three types (Local, Foreign, Completed)
|
|
|
* **2.8.1** `Local` change status means direct local modification occurred.
|
|
|
* **2.8.2** A `local` change overrides all other types and always takes the status.
|
|
|
* **2.8.3** `Foreign` change status means the change was received from elsewhere after a flush.
|
|
|
* **2.8.4** A `foreign` change overrides a `completed` change.
|
|
|
* **2.8.5** `Completed` change status means the change is confirmed and finished.
|
|
|
* **2.9** It must be possible to clear the change status to manually discard.
|
|
|
* **2.10** Frames cannot be copied.
|
|
|
* **2.11** Frames can be moved.
|
|
|
#### 2.1 General Creation Rules
|
|
|
* **2.1.1** A `Feed` class must manage the creation of frames, it can be the only creator.
|
|
|
* **2.1.2** Frames cannot be copied.
|
|
|
* **2.1.3** Frames can be moved.
|
|
|
* **2.1.4** Frames are associated with a valid source identifier by `Feed`.
|
|
|
* **2.1.5** `Frame` id and timestamp together are unique within the `Feed`.
|
|
|
* **2.1.6** Timestamp at creation must be newer than any previously created or received.
|
|
|
|
|
|
#### 2.2 General Modification Rules
|
|
|
* **2.2.1** A `Frame` can be modified only prior to flushing (aka. transmission).
|
|
|
* **2.2.2** Modifications after flushing are discarded.
|
|
|
* **2.2.3** A `Frame` can only be flushed once.
|
|
|
* **2.2.4** Modifications prior to flushing are local to the frame only.
|
|
|
* **2.2.5** It must be possible to clear the change status to manually discard.
|
|
|
|
|
|
#### 2.3 Modification Types
|
|
|
* **2.3.1** Modifications are one of three types (`local`, `foreign`, `completed`)
|
|
|
* **2.3.2** `local` change status means direct local modification occurred.
|
|
|
* **2.3.3** A `local` change overrides all other types and always takes the status.
|
|
|
* **2.3.4** `foreign` change status means the change was received from elsewhere after a flush.
|
|
|
* **2.3.5** A `foreign` change overrides a `completed` change.
|
|
|
* **2.3.6** `completed` change status means the change is confirmed and finished.
|
|
|
* **2.3.7** `foreign` and `completed` changes are applied by `Feed` prior to any `local` changes or access.
|
|
|
|
|
|
### 3. Receiving Frames
|
|
|
|
|
|
### 4. Transmitting Frames
|
|
|
|
|
|
### 5. Memory Management
|
|
|
|
|
|
## Discussion
|
|
|
Each frame is involved in a number of stages within the system, these are:
|
|
|
1. Formation
|
... | ... | |