Re: [boost] Flow-based programming library for Boost?

Subject: Re: [boost] Flow-based programming library for Boost?
From: Marcus Tomlinson (themarcustomlinson_at_[hidden])
Date: 2012-12-09 03:13:37

Hi Julian, thanks for the post. I see a pattern forming :) I think I need to make my documentation clearer in a number of places.

Ok, in DSPatch, circuits provide 2 main purposes: encapsulation of a component network, and parallel processing control (see more on how parallel processing is done see: http://www.adaptaudio.com/DSPatch/spec_page.html). Components don't have to be added to a circuit to be routed together, this is just recommended due to the advantages (mentioned above) gained in this approach. Components have ConnectInput / DisconnectInout methods that can be called directly in order to create component networks outside of a circuit.

You are correct, there isn't a way to extract multiple values from a single input. This is because each component input can only accept one wire at a time. When another wire is connected to an input that already has a connected wire, that wire is replaced with the new one. This is not the case with outputs though. One output can be distributed to multiple inputs. This is definitely something that should be explained explicitly (I'll add it to the list).

I don't see dynamic typing as a limitation, I see it as quite useful. Lets say your processing an input stream of audio samples. With dynamic typing, you can adjust the audio's sample size at run-time and have the component input adapt dynamically without breaking flow.

I also have to disagree with you that object-oriented design has nothing to offer to dataflow programming, but perhaps this is just one man's opinion against other.

On 09 Dec 2012, at 5:02 AM, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:

> 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
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost