[boost] [gsoc] the signal network library is now the dataflow library

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-08-07 00:28:02

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