... | ... | @@ -16,11 +16,15 @@ This class manages the streaming of `FrameSet`s. It is entirely responsible for |
|
|
## Discussion
|
|
|
There are two primary modes to this class, one is being the owner of a generating source who injects Frames and the other is an observer who receives Frames but has the ability to modify the state. A single Feed class may take on both roles depending on the frame set identifier.
|
|
|
|
|
|
**Question: How is the owner/non-owner distinction formed and managed?** Perhaps when a `FrameCreator` object is created it then puts that source ID into ownership mode? Similarly, if it receives a `FrameSet` from a source ID before any `FrameCreator` is made then that source is fixed into non-owner mode and `FrameCreator` objects cannot be made. This seems too restrictive. Another option is that if there is no `onFrameSet` handler registered for a source then received changes are dumped into a waiting new `Frame`, otherwise they are not and are instead output through the handler. Can a received frame be dispatched whilst a new frame is being formed? It raises questions about the atomicity of state. The answer would have to be no. What about loopback where an `onFrameSet` handler may be wanted? Is the only option therefore to explicitly request a different mode? Or could it be restricted such that reply `Frame`s can only be created inside an `onFrameSet` event and that this is distinct from `Frame`s created outside of the event? A further option is that the nature of the frame is encoded into the stream with a flag, allowing some received frames to be treated as replies to merge into next creation, or to be treated as primary frames that form into a frameset. This is probably required since the same machine/instance could generate both kinds of response.
|
|
|
**Question: How is the owner/non-owner distinction formed and managed?** Perhaps when a `FrameCreator` object is created it then puts that source ID into ownership mode? Similarly, if it receives a `FrameSet` from a source ID before any `FrameCreator` is made then that source is fixed into non-owner mode and `FrameCreator` objects cannot be made. This seems too restrictive. Another option is that if there is no `onFrameSet` handler registered for a source then received changes are dumped into a waiting new `Frame`, otherwise they are not and are instead output through the handler. Can a received frame be dispatched whilst a new frame is being formed? It raises questions about the atomicity of state. The answer would have to be no. What about loopback where an `onFrameSet` handler may be wanted? Is the only option therefore to explicitly request a different mode? Or could it be restricted such that reply `Frame`s can only be created inside an `onFrameSet` event and that this is distinct from `Frame`s created outside of the event? A further option is that the nature of the frame is encoded into the stream with a flag, allowing some received frames to be treated as replies to merge into next creation, or to be treated as primary frames that form into a frameset. This is probably required since the same machine/instance could generate both kinds of response. The problem with `ResponseFrameCreator` approach is security, anyone could send a `PrimaryFrame` when that should not be possible.
|
|
|
|
|
|
Hence the following is true:
|
|
|
* Have a `ResponseFrameCreator` to generate frames that are not complete entities
|
|
|
* Use flags within `Frame` and streams to indicate `primary` vs `reponse` frames.
|
|
|
* Response frames accumulate changes into a primary frame awaiting creation.
|
|
|
* Non-response frames (primary frames) generate `onFrameSet` events when received instead.
|
|
|
* Allow for security by filtering primary frames sent by wrong author.
|
|
|
* Allow certain channels to be restricted to prevent change in response frames.
|
|
|
|
|
|
It should be possible to merge multiple sources into a single frameset, currently this occurs inside the `Stream` objects through a multiplexing/demultiplexing process.
|
|
|
|
... | ... | |