Discussion on Boost Community Feedback

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

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 __timedgenerator_ and mutex. 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.