Boost logo

Boost :

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

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?)


Boost list run by bdawes at, gregod at, cpdaniel at, john at