... | ... | @@ -96,6 +96,8 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
#### 4.1 General Protocol
|
|
|
* **4.1.1** Transmission (or recording) occurs upon flush.
|
|
|
* **4.1.2** `flushing` can occur on a per channel or entire `Frame` basis.
|
|
|
* **4.1.3** A sender may filter changes and not transmit to all parties.
|
|
|
* **4.1.4** Filtering can occur at receivers request or subject to authorisation.
|
|
|
|
|
|
#### 4.2 Owner Protocol
|
|
|
* **4.2.1** Changes marked as `local` or `foreign` are transmitted.
|
... | ... | @@ -105,12 +107,21 @@ Data is synchronised and organised into discrete frames that are represented by |
|
|
* **4.3.1** Changes marked as `local` are transmitted.
|
|
|
* **4.3.2** `foreign` or `completed` changes are ignored.
|
|
|
|
|
|
#### 4.4 Flush Events
|
|
|
* **4.4.1** Flush events occur for `local` or `foreign` changes.
|
|
|
* **4.4.2** Flush events are dispatched only after transmission has occurred.
|
|
|
* **4.4.3** Flush events may occur in parallel.
|
|
|
* **4.4.4** One flush event occurs per changed channel.
|
|
|
* **4.4.5** `aggregate` channels with multiple changes result in a single event.
|
|
|
* **4.4.6** `Frame` and channel number are provided to event handler.
|
|
|
* **4.4.7** The change status remains on the channels within the `Frame`.
|
|
|
|
|
|
### 5. Memory Management
|
|
|
* **5.1** `Frame`s are created from a memory pool.
|
|
|
* **5.2** Upon destruction, channel data is not removed but is transferred to the pool.
|
|
|
* **5.3** Channels are marked as `stale` if the data contents reflect old pool data.
|
|
|
* **5.4** The pool should be maintained at a minimal size.
|
|
|
* **5.5** The pool may expand or contract as necessary.
|
|
|
* **5.5** The pool may expand or contract as necessary but infrequently.
|
|
|
|
|
|
## Discussion
|
|
|
Each frame is involved in a number of stages within the system, these are:
|
... | ... | |