"Phil Endecott" <spam_from_boost_dev@chezphil.org> writes:
- 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? Perhaps the review manager could comment.
The roles of the layers are (Stjepan feel free to correct me) as follows: -- The Generic Support layer specifies a generic interface (a set of concepts) of any dataflow framework. The purpose of the Generic support layer is to enable generic code that is parameterized over a particular dataflow framework. The library gives an example of such code: Dataflow.Blueprint. -- Dataflow.signals is one particular instance of a framework that conforms to the Generic Support Layer's interface (the library gives an example of another, VTK). Per the request of the submitter, the library under review is the Dataflow.Signals library. As a review manager, I will interpret a positive vote to mean support for including the Dataflow.Signals library to Boost, without any expectations or conditions regarding the other layers. The division between the layers is not clear cut, as the Signals layer does rely on the Generic layer. The components that are necesessary to include form the Generic layer will not be part of Dataflow.Signals's public interface. Of course, the usefulness of Dataflow.Signals as a stand-alone library is a relevant criterion in a review. The presence of the other layers gives the bigger picture, and shows what the author plans to bring forward in the future. I'm assuming that their own separate reviews will be required for those layers. Best Regards, Jaakko Järvi Review Manager