Marcus Tomlinson wrote:
Is there any interest out there for a library that allows you to create fast, efficient flow-based programs with an easy-to-use object-oriented interface? (http://en.wikipedia.org/wiki/Flow-based_programming)
I've created an open-source library that does this, called "DSPatch" ( http://sourceforge.net/projects/dspatch) and would like to contribute it to the Boost Libraries.
I'm certainly interested in a Boost library that offers efficient flow-based multithreading with an interface that is as simple as possible. In fact I have some ideas of my own which I would gladly present to the mailing list when I find more time. As has been pointed out by other people, there are lots of dataflow libraries out there, all offering similar functionality. I believe the reason for this is that it's hard to get right. In particular, it's hard to offer the functionality through an interface that is truly simple enough. I think your proposal suffers from this same problem. As far as I'm concerned users should not need to inherit from a class in order to do flow-based programming, nor should they need to create a circuit object to provide wiring between the working components -- let alone have to invoke methods on said object for each worker /and/ for each connection. The connection methods have four arguments, which is too much. On top of that I think a dataflow programming library can and should be more powerful. Your framework allows for many-to-many connections, but as far as I can tell from your documentation there are no standard facilities that handle generic patterns such as distributing worker output over multiple receivers. There doesn't seem to be a way to directly extract multiple values in succession from an input DspSignal(Bus). Polymorphism on the connections is handled by dynamic typing while it could be static. I suspect there are more limitations. Finally I believe object oriented design offers no advantage for dataflow programming. It's not really in line with common Boost style either. Concluding, while I fullheartedly agree with your intentions, I would vote against your library if you were to submit it for a formal review. I'm sorry to say this but I think Boost needs something that is both simpler and more flexible. -Julian