@@ -18,6 +18,10 @@ There are two primary modes to this class, one is being the owner of a generatin
**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.
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.
It should be possible to merge multiple sources into a single frameset, currently this occurs inside the `Stream` objects through a multiplexing/demultiplexing process.
