The summer of code signal network project has taken a turn for the generic, and is now called the Dataflow library (you can think of dataflow programming as "programming by specifying the flow of data through data processing components"). Basically, after originally focusing on using Boost.Signals as the data transport mechanism, I started exploring another data transport mechanism (using simple pointers, and processing the data using Phoenix expressions), which helped me extract some generic dataflow concepts. I have posted the documentation at: http://dancinghacker.com/code/dataflow/ A few notes about the docs, so you know what you're looking at: * The Dataflow.Signals docs are still in transition - if something is confusing, your best bet is to look at the examples. If the examples are confusing... let me know :-) * the doxygen generated reference is broken * I'm still thinking of how to best express the concepts. Even though the documentation (and the code) are still in a "slight" state of flux, at this point I would rather put something out there to get feedback than wait to get everything ironed out. By reading the docs you should get a good idea of where the project has gone, and any comments you might have are very very very welcome. If you want to look at the code, it is in the sandbox (SOC/2007/signals), the tests and examples have been tested with GCC 4.0.1/darwin and MSVC (test_disconnect is known to fail). The summary of the project contributions thus far: 1) A minimal generic dataflow layer which is data-transport mechanism independent, which gives a glimpse of what a generic dataflow library can offer. This layer currently supports component connection, invocation, and grouping. 2) A relatively complete implementation supporting Boost.Signals as the data transport mechanism. This has a number of generally useful signal-based components for dataflow networks, and provides easy connectability. 3) An experimental implementation using mostly pointers as the data transport mechanism + support for Phoenix expressions to process the data. There are some interesting things brewing here - one of the more interesting (to me) is the notion of "inferred" connections (connections that are not stored in memory but inferred from the component). There are some examples of a fibonacci sequence generator that use this (see the docs under Dataflow.Phoenix), and in the future I would also like to experiment with encoding dataflow networks in Proto expression trees. For the GSoC phase I plan to iron out items 1 and 2. Your feedback would be most helpful in deciding what to focus on - what do you find useful? what do you find confusing, awkward, or incorrect? that, and any comments on the implementation are most welcome. It would help me wrap up a more useful GSoC project outcome, as well as plan the future direction of this library. Thank you in advance! Stjepan