@@ -16,7 +16,7 @@ This class manages the streaming of `FrameSet`s. It is entirely responsible for
...
@@ -16,7 +16,7 @@ This class manages the streaming of `FrameSet`s. It is entirely responsible for
## Discussion
## 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.
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.
**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?
It should be possible to merge multiple sources into a single frameset, currently this occurs inside the `Stream` objects through a multiplexing/demultiplexing process.
It should be possible to merge multiple sources into a single frameset, currently this occurs inside the `Stream` objects through a multiplexing/demultiplexing process.