Design/Feeds.md

@@ -25,3 +25,19 @@ What about stream discovery and enabling discovered streams within a feed? Most
 Feeds can also produce output streams with particular URIs, it needs to be possible to add/remove these. Each output stream may also have filtering applied by sender to limit which sources and frame sets can be sent on that stream.
 
 Should the feed class be responsible for providing all meta-data about added streams, even if those streams are not enabled for receiving data? What is that meta-data?
+
+**Question: Should there be a class that manages the allocation of specific frames (with a specific ID)?** `Feed` would generate an instance that can then be used elsewhere to get frames on demand. Or perhaps this is a wrapper of the `Pool` class? The answer should be yes, a `FrameCreator` class.
+
+Hence this means the following:
+* Have a `FrameCreator` class that creates `Frame` instances with a pre-coded ID and attached to a specific feed.
+* The `FrameCreator` can be freely moved around and copied.
+* The `FrameCreator` can make frames at specific timestamps or at current time.
+* An `IntervalFrameCreator` also supports timer generator of `Frame` objects with a capture trigger also, inheriting `FrameCreator`.
+
+**Question: Is it ever the case that a `FrameSet` is needed for transmission?** A `FrameSet` is used to synchronise at receive but there is little reason to also synchronise at send as well. In which case the external interface of `Feed` need only apply a means of allocating individual `Frame` objects. There could in addition be a *loopback* option within `Feed` to allow the gathering of `Frame`s into `FrameSet`s.
+
+Hence this means the following:
+* Provide a means to generate a `Frame` instance with specific ID and timestamp
+* Provide a means to send that `Frame` (probably using the `flush` mechanism)
+* Allow local stream loopback.
+* Received `Frame`s are always contained within a `FrameSet` instance.
\ No newline at end of file