The following summarizes some of the suggestions / comments given by the Boost community, and what has been done to incorporate this feedback.

Douglas Gregor has suggested the dataflow library could be applied to VTK and http://www.boost.org/libs/iostreams/doc/index.html, gave helpful suggestions on how deal with fused/unfused issues in the Dataflow.Signals documentation and the code, and suggested making the examples more connected to the introductory examples and including visual diagrams for the dataflow networks.

  • I have added an example of VTK support, but the library is not quite ready for http://www.boost.org/libs/iostreams/doc/index.html.
  • As per Doug's suggestion, I have made the documentation focus on the unfused components, and made the unfused components default in the implementation.
  • I have started ASCII visual diagrams in the documentation.
  • Examples still need to be expanded and integrated more.

Jake Voytko suggested having master table of Dataflow.Signals components describing their use, adding instructions on linking with the library, and other suggestions on improving the documentation.

Tobias Schwinger indicated that the library could be used for pulling rather than pushing data.

  • An example which illustrates this has been addded.

James Jones suggested that a ||-like operator could be used for branching, and >> for chaining.

  • operator >= which was orignally used for branching has been replaced with operator |.
  • Since the most straightforward way for me to implement chaining/branching is using a left-to-right operator for one and a right-to-left operator for the other, I decided to stay with >>= as the chaining operator.

Paolo Coletta suggested a "video_generator >>= ( effect1 && effect2 ) >>= image_sum" - like syntax that would allow parallel processing of signals (identified as the "join" pattern by Yigong Liu)

  • I have started to implement thread-related components in [timed_storage], mutex and condition. More sophisticated threading components, control and syntax to follow.

Yigong Liu suggested enhanced support for common network topologies, such as mesh.

  • I have implemented a prototype chain topology to get a start on this concept.

Braddock Gaskill pointed out the relationship with the "pipes and filters" pattern, and suggested the possibility of using functions as filters. He also suggested the library would me more useful if different functions executed in parallel threads, or were queued to specific worker threads, if the library would provide functionality to control and schedule the execution of the invoked functions, or traverse the call graph.

  • In light of the possible connection with the "pipes and filters" pattern, the base object for signal network components which receive a signal and send a signal has been changed to filter. I was not successful in finding a formal definition of what "pipes and filters" semantics should be, so I am not sure whether this is appropriate.
  • function now offers the proposed functionality of converting functions into filters.
  • Threading and scheduling of the invoked functions is something I plan to address.
  • Providing a call graph would be a great feature, but I am not sure what the best way to address that is, since each component might be of a different type. Perhaps a graph in which only the edges are labeled (with connection objects) would be doable and useful.