Re: [boost] Review Request: Dataflow.Signals

From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2008-03-15 21:02:18

From: "Ronald Garcia" <garcia_at_[hidden]>
> I have received your request and have added Dataflow.Signals to the
> review queue.

I'm really excited about this library but is it ready for review yet?

Stjepan has kindly kept us up to date with a v0.80/81 and later 0.90 with a 
fledgling blueprint layer but, playing devil's advocate, perhaps more 
discussion of what it's trying to solve and how it might make use of other 
libraries might be useful prior to review. I'm concerned that its fate might 
be similar to the first revision of the logging library otherwise. I suspect 
there are many differing/conflicting requirements for a dataflow library.

When I've done similar things in the past the critical decision has been 
whether dataflows are defined at compile time or run-time and what the 
strategies are for information, buffer and connection management.

Even in the last couple of days several areas of functionality and interface 
have been discussed. Compiler support seems weak too on very popular 
compilers.

Perhaps Stjepan could comment further on his plans between now and review. 
Its a worthwhile library and something I'm personally very interested in but 
I'd love to see it fleshed out a bit more with a reasonable application 
example. This is a library that is not really core to many tasks and 
probably needs to show its mettle through use.

Is it intended to tackle building processing sequences on the fly. Is it 
lightweight enough to support fine-grained building blocks where connection 
setup could end up dominating run time if not done well. Is it simply about 
ease of use in putting together blocks? Is it's uniqueness about supporting 
dynamic run-time sequence configurability rather than compile-time?

I guess I'd like to see the rationale for what its good at and then see 
compelling evidence (in the form of an example?)

Paul