On Tue, Sep 2, 2008 at 2:53 PM, Phil Endecott <spam_from_boost_dev@chezphil.org> 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