... | ... | @@ -11,8 +11,10 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
|
|
|
#### 1.1 General Properties
|
|
|
* **1.1** Contains up to 2^32 number of data channels.
|
|
|
* **1.8** A `Frame` must include an ID and timestamp in milliseconds.
|
|
|
* **1.9** A `Frame` must provide a lock to be used manually, except for `flushing` where is is locked automatically.
|
|
|
* **1.2** A `Frame` must include an ID and timestamp in milliseconds.
|
|
|
* **1.3** A `Frame` must provide a lock to be used manually, except for `flushing` where is is locked automatically.
|
|
|
* **1.4** Channels can also contain cached encoded data.
|
|
|
* **1.5** Encoded data is removed if a local change is made.
|
|
|
|
|
|
#### 1.2 Channel Data Types
|
|
|
* **1.2.1** A data channel can in principle be any type.
|
... | ... | @@ -43,6 +45,9 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
* **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.1.7** Multiple modifying frames can be created by non-owner for each `Frame` generated by the owner, these being combined as per storage mode.
|
|
|
* **2.1.8** A `Frame` with one ID may be merged into a `Frame` with a different ID.
|
|
|
* **2.1.9** Merging of frames results in all merged channels being marked as `local` changes.
|
|
|
* **2.1.10** Cached encoded data will be copied during a copy merge.
|
|
|
|
|
|
#### 2.2 General Modification Rules
|
|
|
* **2.2.1** A `Frame` can be modified only prior to flushing (aka. transmission).
|
... | ... | |