Re: [boost] [review] Dataflow Review starts today, September 1st

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-09-02 21:51:33

On Tue, Sep 2, 2008 at 2:53 PM, Phil Endecott
<spam_from_boost_dev_at_[hidden]> wrote:
>
>> - Do you think the library should be accepted as a Boost library?
>
> Is the work proposed for inclusion in Boost in its current form?  (In which
> case, we should take into account its scope and reject it if we consider it
> too limited.)  Or are we to review this as a first part of something, with
> subsequent parts to be reviewed separately before anything is finally
> accepted?  For example, am I right in thinking that the Signals component is
> not even usable without the Generic component, which is not being reviewed?

I was intending the Generic layer to be considered as an
implementation detail of the Dataflow.Signals layer.  If
Dataflow.Signals got accepted into boost, it would definitely need the
generic layer to function, but I would not expose the generic layer
(in the docs, for example) until it underwent its own review and got
reviewed favorably.  I left the docs for the other layers included for
the review so that reviewers can have access to as much information as
possible, but as was indicated in the review statement, please treat
the other layers as implementation details (e.g., the generic layer)
or as proof of concept examples (e.g., the Blueprint layer or the GUI
editor based on it).

>  Perhaps the review manager could comment.
>

A more official opinion would be great.

> A couple of initial thoughts, to provoke discussion:
>
> - I hope everyone has seen the 2-dimensional "ASCII Art" dataflow graphs
> using operator overloading:
>
> [snip]
>
> My comment: if the operator overloading were good enough, you wouldn't need
> the picture in the comment block.  Since it isn't good enough, why not stick
> to connect():
>

I agree that the operator syntax isn't always perfectly readable,
especially until one gets used to it.  Would it be useful if I
provided both operator-based and connect-based construction of
networks in the examples?  I think in some cases the operator syntax
is good enough (and if you have suggestions on how you would like the
operator syntax to look so that it is more readable, I'm open to
changing it).

>
> - The hard aspects of this sort of thing are buffering, distributing work
> over threads, and so on.  I don't think you have any of that; the components
> always process one datum at a time.  As it happens I've recently written
> some code that grabs an image from a web cam, annotates it with some text
> and shows it on the screen - very much like your example.  This was using
> the video4linux2 API.  To get a respectable framerate you need to queue up a
> number of frame requests in the kernel, but if you queue too many you'll get
> too much latency.  I honestly can't say that I feel this library would have
> made this code any easier to write, or given any better results.  I wonder
> if there are more complex motivating examples that would better illustrate
> it?
>

I've been working on an example that uses thread_safe_signals and the
threadpool library to allow asynchronous tasks.  It was based on a
suggestion by Manuel Jung - the thread can be seen here:
http://tinyurl.com/5huap7 [nabble]

I am planning to provide a couple more examples of how this could be
added to Dataflow.Signals, based on Manuel Jung's latest feedback.  Is
this closer to what you would find useful?

Thank you for your feedback,

Stjepan