[Boost-commit] svn:boost r41427 - in sandbox/SOC/2007/signals: boost/dataflow boost/dataflow/blueprint boost/dataflow/connection boost/dataflow/signals boost/dataflow/signals/component boost/dataflow/signals/connection boost/dataflow/support boost/dataflow/support/port/detail libs/dataflow/build/xcodeide/signal_network.xcodeproj libs/dataflow/doc libs/dataflow/doc/blueprint libs/dataflow/doc/concepts libs/dataflow/doc/introduction libs/dataflow/example/blueprint libs/dataflow/example/signals libs/dataflow/test libs/dataflow/test/signals

From: stipe_at_[hidden]
Date: 2007-11-27 21:20:32

Author: srajko
Date: 2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
New Revision: 41427
URL: http://svn.boost.org/trac/boost/changeset/41427

Log:
prepping 0.8.1 - update docs (esp. concept), remove Mechanism from all but port-related concepts, support extraction in Blueprint...
Added:
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation.hpp
      - copied, changed from r41189, /sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection.hpp
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation_t.hpp
      - copied, changed from r41189, /sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection_t.hpp
   sandbox/SOC/2007/signals/boost/dataflow/support/complemented_port.hpp   (contents, props changed)
   sandbox/SOC/2007/signals/boost/dataflow/support/runtime.hpp   (contents, props changed)
   sandbox/SOC/2007/signals/boost/dataflow/support/tags.hpp   (contents, props changed)
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/binary_operable.qbk
      - copied, changed from r41347, /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/concepts.qbk
      - copied, changed from r41347, /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/unary_operable.qbk
      - copied, changed from r41347, /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk
   sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk
      - copied, changed from r41189, /sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk
Removed:
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection.hpp
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection_t.hpp
   sandbox/SOC/2007/signals/boost/dataflow/signals/runtime_support.hpp
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts.qbk
   sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk
   sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk
Text files modified: 
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation.hpp                         |    54 ++++                                    
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation_t.hpp                       |    52 +++                                     
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/component.hpp                                |    34 +-                                      
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/get_port.hpp                                 |    15                                         
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/network.hpp                                  |    42 +--                                     
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/port.hpp                                     |    93 ++++++--                                
   sandbox/SOC/2007/signals/boost/dataflow/blueprint/port_t.hpp                                   |   183 +++++++++++----                         
   sandbox/SOC/2007/signals/boost/dataflow/connection/port_map.hpp                                |    10                                         
   sandbox/SOC/2007/signals/boost/dataflow/signals/component/storage.hpp                          |    72 ++++-                                   
   sandbox/SOC/2007/signals/boost/dataflow/signals/connection/slot_selector.hpp                   |     4                                         
   sandbox/SOC/2007/signals/boost/dataflow/signals/support.hpp                                    |    64 ++++                                    
   sandbox/SOC/2007/signals/boost/dataflow/support.hpp                                            |     3                                         
   sandbox/SOC/2007/signals/boost/dataflow/support/binary_operation.hpp                           |    59 ++++                                    
   sandbox/SOC/2007/signals/boost/dataflow/support/component.hpp                                  |    72 +++++-                                  
   sandbox/SOC/2007/signals/boost/dataflow/support/component_operation.hpp                        |    18                                         
   sandbox/SOC/2007/signals/boost/dataflow/support/keyed_port.hpp                                 |    46 ++-                                     
   sandbox/SOC/2007/signals/boost/dataflow/support/port.hpp                                       |   117 +++------                               
   sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/port_traits_sequence.hpp           |     2                                         
   sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/proxy_port_traits_sequence.hpp     |     2                                         
   sandbox/SOC/2007/signals/boost/dataflow/support/reflective_component.hpp                       |     2                                         
   sandbox/SOC/2007/signals/libs/dataflow/build/xcodeide/signal_network.xcodeproj/project.pbxproj |    48 ++-                                     
   sandbox/SOC/2007/signals/libs/dataflow/doc/Jamfile.v2                                          |    21 +                                       
   sandbox/SOC/2007/signals/libs/dataflow/doc/blueprint/blueprint.qbk                             |    23 +                                       
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/binary_operable.qbk                        |   417 ------------------------------------    
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk                              |   434 ++-----------------------------------   
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/concepts.qbk                               |   355 +-----------------------------          
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/port.qbk                                   |    24 -                                       
   sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/unary_operable.qbk                         |   454 ----------------------------------------
   sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk                                        |    58 ++--                                    
   sandbox/SOC/2007/signals/libs/dataflow/doc/future.qbk                                          |    30 +-                                      
   sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/blueprint_example.qbk                  |    46 ++-                                     
   sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gil_example.qbk                        |   237 ++++++++++----------                    
   sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk                       |    61 +++--                                   
   sandbox/SOC/2007/signals/libs/dataflow/example/blueprint/blueprint_example.cpp                 |    20                                         
   sandbox/SOC/2007/signals/libs/dataflow/example/signals/gil_example.cpp                         |    24 +-                                      
   sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_chain.cpp                             |     2                                         
   sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_disconnect.cpp                        |    22 +                                       
   sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_socket.cpp                            |     2                                         
   sandbox/SOC/2007/signals/libs/dataflow/test/test_component.cpp                                 |    10                                         
   sandbox/SOC/2007/signals/libs/dataflow/test/test_port.cpp                                      |     8                                         
   sandbox/SOC/2007/signals/libs/dataflow/test/test_reflective_component.cpp                      |     6                                         
   41 files changed, 1064 insertions(+), 2182 deletions(-)

Copied: sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation.hpp (from r41189, /sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection.hpp)
==============================================================================
--- /sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -11,14 +11,60 @@
 
 namespace boost { namespace dataflow { namespace blueprint {
 
-class connection
+template<typename Operation>
+class binary_operation
 {
 public:
-    virtual void connect(port &producer, port &consumer)=0;
-    virtual std::auto_ptr<connection> copy() const=0;
-    virtual ~connection() {};
+    virtual void invoke(port &producer, port &consumer)=0;
+    virtual std::auto_ptr<binary_operation> copy() const=0;
+    virtual ~binary_operation() {};
 };
 
+template<typename Operation>
+bool are_binary_operable(port &producer, port &consumer)
+{
+    if ((producer.traits().category().uuid() != 0)
+            || (consumer.traits().category().uuid() != 1))
+        return false;
+    
+    if (producer.is_complemented_port())
+    {
+        complemented_port &cproducer = static_cast<complemented_port &>(producer);
+        return cproducer.is_operable_with_complement<Operation>()
+            && (cproducer.complement_type_info()
+                == consumer.port_type_info());
+    }
+
+    if (consumer.is_complemented_port())
+    {
+        complemented_port &cconsumer = static_cast<complemented_port &>(consumer);
+        return cconsumer.is_operable_with_complement<Operation>()
+            && (cconsumer.complement_type_info()
+            == producer.port_type_info());
+    }
+
+    return false;
+}
+
+template<typename Operation>
+shared_ptr<binary_operation<Operation> > get_binary_operation(port & producer, port & consumer)
+{
+    if(!are_binary_operable<Operation>(producer, consumer))
+        throw std::exception();
+    if (producer.is_complemented_port())
+        return static_cast<complemented_port &>(producer).operation<Operation>();
+    if (consumer.is_complemented_port())
+        return static_cast<complemented_port &>(consumer).operation<Operation>();
+    return shared_ptr<binary_operation<Operation> >();
+}
+
+void extract(port & producer, port & consumer)
+{
+    get_binary_operation<operations::extract>(producer, consumer)->invoke(producer, consumer);
+}
+
+
+
 } } } // namespace boost::dataflow::blueprint
 
 #endif // BOOST_DATAFLOW_BLUEPRINT_CONNECTION_HPP
\ No newline at end of file

Copied: sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation_t.hpp (from r41189, /sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection_t.hpp)
==============================================================================
--- /sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection_t.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/binary_operation_t.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -6,26 +6,56 @@
 #ifndef BOOST_DATAFLOW_BLUEPRINT_CONNECTION_T_HPP
 #define BOOST_DATAFLOW_BLUEPRINT_CONNECTION_T_HPP
 
-#include <boost/dataflow/blueprint/connection.hpp>
+#include <boost/dataflow/blueprint/binary_operation.hpp>
 #include <boost/dataflow/support/binary_operation.hpp>
 
-#include <boost/type_traits/remove_reference.hpp>
-
 namespace boost { namespace dataflow { namespace blueprint {
 
-template <typename Mechanism, typename ProducerPort, typename ConsumerPort>
-class connection_t : public connection
+namespace detail
+{    
+    template <typename Operation, typename Mechanism, typename ProducerPort, typename ConsumerPort>
+    typename disable_if<
+            dataflow::are_binary_operable<
+                Operation,
+                Mechanism,
+                ProducerPort,
+                ConsumerPort
+            >
+        >::type
+    call_binary_operation(port &producer, port &consumer)
+    {
+        throw std::exception();
+    }
+    
+    template <typename Operation, typename Mechanism, typename ProducerPort, typename ConsumerPort>
+    typename enable_if<
+            dataflow::are_binary_operable<
+                Operation,
+                Mechanism,
+                ProducerPort,
+                ConsumerPort
+            >
+        >::type
+    call_binary_operation(port &producer, port &consumer)
+    {
+            dataflow::binary_operation<Operation, Mechanism>(
+            *(ProducerPort *) producer.get(),
+            *(ConsumerPort *) consumer.get());
+    }
+}
+
+template <typename Operation, typename Mechanism, typename ProducerPort, typename ConsumerPort, typename Enable=void>
+class binary_operation_t : public binary_operation<Operation>
 {
 public:
-    virtual void connect(port &producer, port &consumer)
+    void invoke(port &producer, port &consumer)
     {
-        dataflow::binary_operation<operations::connect, Mechanism>(
-            *(typename remove_reference<ProducerPort>::type *) producer.get(),
-            *(typename remove_reference<ConsumerPort>::type *) consumer.get());
+        detail::call_binary_operation<Operation, Mechanism, ProducerPort, ConsumerPort>(
+            producer, consumer);
     }
-    virtual std::auto_ptr<connection> copy() const
+    virtual std::auto_ptr<binary_operation<Operation> > copy() const
     {
-        return std::auto_ptr<connection>(new connection_t(*this));
+        return std::auto_ptr<binary_operation<Operation> >(new binary_operation_t(*this));
     }
 };
 

Modified: sandbox/SOC/2007/signals/boost/dataflow/blueprint/component.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/component.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/component.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -7,13 +7,15 @@
 #define BOOST_DATAFLOW_BLUEPRINT_COMPONENT_HPP
 
 #include <boost/dataflow/blueprint/get_port.hpp>
-#include <boost/dataflow/support/reflective_component.hpp>
+#include <boost/dataflow/support/component.hpp>
 #include <boost/dataflow/support/component_operation.hpp>
 #include <boost/dataflow/support/binary_operation.hpp>
 
 #include <boost/mpl/size.hpp>
+#include <boost/ptr_container/ptr_vector.hpp>
 #include <boost/shared_ptr.hpp>
 
+
 namespace boost { namespace dataflow { namespace blueprint {
 
 struct mechanism;
@@ -22,40 +24,48 @@
 {
 public:
     virtual void invoke()=0;
-    virtual int num_ports() const=0;
-    virtual std::auto_ptr<port> get_port(int port_num)=0;
+    virtual size_t num_ports() const=0;
+    virtual port & get_port(int port_num)=0;
     
     virtual std::auto_ptr<component> copy() const=0;
     virtual ~component() {};
 };
 
-template<typename Mechanism, typename Component>
+template<typename Component>
 class component_t : public component
 {
 public:
-    component_t() {}
+    component_t() {component_t_();}
     template<typename T0>
-    component_t(const T0 &t0) : c(t0) {}
+    component_t(const T0 &t0) : c(t0) {component_t_();}
+    component_t(const component_t &rhs) : c(rhs.c)
+    {   component_t_(); }
     
     void invoke()
     {
-        component_operation<operations::invoke, Mechanism>(c);
+        component_operation<operations::invoke>(c);
     }
-    int num_ports() const
+    size_t num_ports() const
     {
-        return mpl::size<typename component_traits_of<Mechanism, Component>::type::ports>::value;
+        return mpl::size<typename component_traits_of<Component>::type::ports>::value;
     }
-    std::auto_ptr<port> get_port(int port_num)
+    port & get_port(int port_num)
     {
-        return blueprint::get_port<Mechanism, Component>(c, port_num);
+        return ports[port_num];
     }
     virtual std::auto_ptr<component> copy() const
     {
-        return std::auto_ptr<component>(new component_t<Mechanism,Component>(*this));
+        return std::auto_ptr<component>(new component_t<Component>(*this));
     }
     Component &get() {return c;}
 private:
+    void component_t_()
+    {
+        for(size_t i=0; i<num_ports(); i++)
+            ports.push_back(blueprint::get_port<Component>(c, i));
+    }
     Component c;
+    ptr_vector<port> ports;
 };
 
 } } } // namespace boost::dataflow::blueprint

Deleted: sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
+++ (empty file)
@@ -1,24 +0,0 @@
-// Copyright Stjepan Rajko 2007. Use, modification and
-// distribution is subject to the Boost Software License, Version
-// 1.0. (See accompanying file LICENSE_1_0.txt or copy at
-// http://www.boost.org/LICENSE_1_0.txt)
-
-#ifndef BOOST_DATAFLOW_BLUEPRINT_CONNECTION_HPP
-#define BOOST_DATAFLOW_BLUEPRINT_CONNECTION_HPP
-
-#include <boost/dataflow/blueprint/port.hpp>
-
-
-namespace boost { namespace dataflow { namespace blueprint {
-
-class connection
-{
-public:
-    virtual void connect(port &producer, port &consumer)=0;
-    virtual std::auto_ptr<connection> copy() const=0;
-    virtual ~connection() {};
-};
-
-} } } // namespace boost::dataflow::blueprint
-
-#endif // BOOST_DATAFLOW_BLUEPRINT_CONNECTION_HPP
\ No newline at end of file

Deleted: sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection_t.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/connection_t.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
+++ (empty file)
@@ -1,34 +0,0 @@
-// Copyright Stjepan Rajko 2007. Use, modification and
-// distribution is subject to the Boost Software License, Version
-// 1.0. (See accompanying file LICENSE_1_0.txt or copy at
-// http://www.boost.org/LICENSE_1_0.txt)
-
-#ifndef BOOST_DATAFLOW_BLUEPRINT_CONNECTION_T_HPP
-#define BOOST_DATAFLOW_BLUEPRINT_CONNECTION_T_HPP
-
-#include <boost/dataflow/blueprint/connection.hpp>
-#include <boost/dataflow/support/binary_operation.hpp>
-
-#include <boost/type_traits/remove_reference.hpp>
-
-namespace boost { namespace dataflow { namespace blueprint {
-
-template <typename Mechanism, typename ProducerPort, typename ConsumerPort>
-class connection_t : public connection
-{
-public:
-    virtual void connect(port &producer, port &consumer)
-    {
-        dataflow::binary_operation<operations::connect, Mechanism>(
-            *(typename remove_reference<ProducerPort>::type *) producer.get(),
-            *(typename remove_reference<ConsumerPort>::type *) consumer.get());
-    }
-    virtual std::auto_ptr<connection> copy() const
-    {
-        return std::auto_ptr<connection>(new connection_t(*this));
-    }
-};
-
-} } } // namespace boost::dataflow::blueprint
-
-#endif // BOOST_DATAFLOW_BLUEPRINT_CONNECTION_HPP
\ No newline at end of file

Modified: sandbox/SOC/2007/signals/boost/dataflow/blueprint/get_port.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/get_port.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/get_port.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -7,7 +7,7 @@
 #define BOOST_DATAFLOW_BLUEPRINT_GET_PORT_HPP
 
 #include <boost/dataflow/blueprint/port_t.hpp>
-#include <boost/dataflow/support/reflective_component.hpp>
+#include <boost/dataflow/support/component.hpp>
 
 #include <boost/mpl/range_c.hpp>
 #include <boost/switch.hpp>
@@ -18,7 +18,7 @@
 
 namespace detail {
 
-template<typename Mechanism, typename Component>
+template<typename Component>
 struct get_port_case
 {
     typedef void result_type;
@@ -27,15 +27,14 @@
     {
         ret.reset(new port_t<
             typename mpl::at_c<
-                typename component_traits_of<Mechanism, Component>::type::ports,
+                typename component_traits_of<Component>::type::ports,
                 Case::value
             >::type,
             typename get_component_port_result_type<
-                Mechanism,
                 mpl::int_<Case::value>,
                 Component
             >::type
-        >(get_component_port<Mechanism, mpl::int_<Case::value>, Component >(c))); \
+        >(get_component_port<mpl::int_<Case::value>, Component >(c))); \
     }
     get_port_case(Component& c, std::auto_ptr<port> &ret) : c(c), ret(ret)
     {}
@@ -45,7 +44,7 @@
 
 } // namespace detail
 
-template<typename Mechanism, typename Component>
+template<typename Component>
 std::auto_ptr<port> get_port(Component &c, int port_num)
 {
     std::auto_ptr<port> ret;
@@ -53,9 +52,9 @@
         int,
         0,
         mpl::size<
-            typename component_traits_of<Mechanism, Component>::type::ports>
+            typename component_traits_of<Component>::type::ports>
         ::value> range;
-    boost::switch_<range>(port_num, detail::get_port_case<Mechanism, Component>(c, ret));
+    boost::switch_<range>(port_num, detail::get_port_case<Component>(c, ret));
     return ret;
 }
 

Modified: sandbox/SOC/2007/signals/boost/dataflow/blueprint/network.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/network.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/network.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -7,7 +7,7 @@
 #define BOOST_DATAFLOW_BLUEPRINT_NETWORK_HPP
 
 #include <boost/dataflow/blueprint/component.hpp>
-#include <boost/dataflow/blueprint/connection_t.hpp>
+#include <boost/dataflow/blueprint/binary_operation_t.hpp>
 
 #include <boost/graph/adjacency_list.hpp>
 #include <boost/graph/copy.hpp>
@@ -17,7 +17,6 @@
 
 namespace boost { namespace dataflow { namespace blueprint {
 
-template<typename Mechanism>
 class network
 {
     struct node_t
@@ -26,15 +25,15 @@
     };
     struct edge_t
     {
-        boost::shared_ptr<connection> ptr;
+        boost::shared_ptr<binary_operation<operations::connect> > ptr;
         int producer_port;
         int consumer_port;
     };
 public:
     typedef boost::adjacency_list<
         boost::vecS, boost::vecS, boost::bidirectionalS, node_t, edge_t> graph_type;
-    typedef typename graph_type::vertex_descriptor component_type;
-    typedef typename graph_type::edge_descriptor connection_type;
+    typedef graph_type::vertex_descriptor component_type;
+    typedef graph_type::edge_descriptor connection_type;
 private:
     struct vc
     {
@@ -73,49 +72,46 @@
     component_type add_component()
     {
         typename graph_type::vertex_descriptor v = add_vertex(g);
-        g[v].ptr.reset(new component_t<Mechanism, Component>());
+        g[v].ptr.reset(new component_t<Component>());
         return v;
     }
     template<typename Component, typename T0>
     component_type add_component(const T0 &t0)
     {
         typename graph_type::vertex_descriptor v = add_vertex(g);
-        g[v].ptr.reset(new component_t<Mechanism, Component>(t0));
+        g[v].ptr.reset(new component_t<Component>(t0));
         return v;
     }
-    template<typename ProducerPort, typename ConsumerPort>
+    template<typename Mechanism, typename ProducerPort, typename ConsumerPort>
     void add_connection(component_type p, int p_port, component_type c, int c_port)
     {
-        add_connection_(p, p_port, c, c_port, new connection_t<Mechanism, ProducerPort, ConsumerPort>());
+        add_connection_(p, p_port, c, c_port, new binary_operation_t<operations::connect, Mechanism, ProducerPort, ConsumerPort>());
     }
     void add_connection(component_type p, int p_port, component_type c, int c_port)
     {
         if (!are_connectable(p, p_port, c, c_port))
             throw(std::exception());
 
-        add_connection_(p, p_port, c, c_port, get_port(p, p_port)->connector());
+        add_connection_(p, p_port, c, c_port,
+            get_binary_operation<operations::connect>(get_port(p, p_port), get_port(c, c_port)));
     }
     bool are_connectable(component_type p, int p_port, component_type c, int c_port)
     {
-        return (
-            (typeid(*get_port(p, p_port)->connector().get())
-                == typeid(*get_port(c, c_port)->connector().get()))
-            && (get_port(p, p_port)->traits().category().uuid() == 0)
-            && (get_port(c, c_port)->traits().category().uuid() == 1));
+        return are_binary_operable<operations::connect>(get_port(p, p_port), get_port(c, c_port));
     }
     void connect()
     {
-        typename graph_type::edge_iterator it;
+        graph_type::edge_iterator it;
         for (it = edges(g).first; it!=edges(g).second; it++)
-            g[*it].ptr->connect(
-                *g[source(*it, g)].ptr->get_port(g[*it].producer_port),
-                *g[target(*it, g)].ptr->get_port(g[*it].consumer_port));
+            g[*it].ptr->invoke(
+                g[source(*it, g)].ptr->get_port(g[*it].producer_port),
+                g[target(*it, g)].ptr->get_port(g[*it].consumer_port));
     }
     component &operator[](component_type c)
     {
         return *g[c].ptr;
     }
-    std::auto_ptr<port> get_port(component_type c, int port)
+    port & get_port(component_type c, int port)
     {
         return g[c].ptr->get_port(port);
     }
@@ -126,10 +122,10 @@
     
 private:
     void add_connection_(component_type p, int p_port, component_type c, int c_port,
-        boost::shared_ptr<connection>)
+        boost::shared_ptr<binary_operation<operations::connect> >)
     {
-        typename graph_type::edge_descriptor e = add_edge(p, c, g).first;
-        g[e].ptr = g[p].ptr->get_port(p_port)->connector();
+        graph_type::edge_descriptor e = add_edge(p, c, g).first;
+        g[e].ptr = get_binary_operation<operations::connect>(get_port(p, p_port), get_port(c, c_port));
         g[e].producer_port = p_port;
         g[e].consumer_port = c_port;        
     }

Modified: sandbox/SOC/2007/signals/boost/dataflow/blueprint/port.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/port.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/port.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -6,58 +6,103 @@
 #ifndef BOOST_DATAFLOW_BLUEPRINT_PORT_HPP
 #define BOOST_DATAFLOW_BLUEPRINT_PORT_HPP
 
+#include <boost/dataflow/support/binary_operation.hpp>
+#include <boost/dataflow/support/complemented_port.hpp>
+#include <boost/dataflow/support/runtime.hpp>
+
+#include <boost/ptr_container/clone_allocator.hpp>
 #include <boost/shared_ptr.hpp>
 #include <string>
 
 namespace boost { namespace dataflow { namespace blueprint {
 
-class connection;
-
-class port_category
-{
-public:
-    port_category(const std::string &name, int uuid)
-        : name_(name), uuid_(uuid)
-    {}
-
-    const char *name() const
-    {   return name_.c_str(); }
-    int uuid() const
-    {   return uuid_; }
-private:    
-    std::string name_;
-    int uuid_;
-};
+template<typename T>
+class binary_operation;
 
 class port_traits
 {
 public:
-    port_traits(const port_category &category) : category_(category)
+    port_traits(const runtime_info &mechanism, const runtime_info &category,
+        const runtime_info &concept_info)
+        : mechanism_(mechanism), category_(category), concept_(concept_info)
     {}
-    const port_category &category() const
-    {   return category_;
-    }
+    const runtime_info &mechanism() const
+    {   return mechanism_; }
+    const runtime_info &category() const
+    {   return category_; }
+    const runtime_info &concept_info() const
+    {   return concept_; }
 private:
-    port_category category_;
+    runtime_info mechanism_;
+    runtime_info category_;
+    runtime_info concept_;
 };
 
 class port
 {
 public:
-    port(const port_category &category) : traits_(category)
+    port(const runtime_info &mechanism, const runtime_info &category,
+        const runtime_info &concept_info)
+        : traits_(mechanism, category, concept_info)
     {}
     const port_traits &traits() const
     {   return traits_; }
     
     virtual void *get()=0;
-    virtual shared_ptr<connection> connector()=0;
+    bool is_complemented_port()
+    {
+        return traits_.concept_info().uuid()
+            == runtime::property<concepts::complemented_port, int>()();
+    }
+    virtual const std::type_info &port_type_info()=0;
     virtual ~port() {};
+    virtual port *clone() const =0;
 private:
     port_traits traits_;
 };
 
+class complemented_port : public port
+{
+public:
+    complemented_port(const runtime_info &mechanism, 
+        const runtime_info &category, const runtime_info &concept_info)
+        : port(mechanism, category, concept_info)
+    {}
+        virtual const std::type_info &complement_type_info()=0;
+    virtual shared_ptr<binary_operation<operations::connect> > connector()=0;
+    virtual shared_ptr<binary_operation<operations::extract> > extractor()=0;
+    template<typename Operation>
+    typename enable_if<
+        is_same<Operation, operations::connect>,
+        shared_ptr<binary_operation<Operation> >
+    >::type operation()
+    {   return connector(); }
+    template<typename Operation>
+    typename enable_if<
+        is_same<Operation, operations::extract>,
+        shared_ptr<binary_operation<Operation> >
+    >::type operation()
+    {   return extractor(); }
+template<typename Operation>
+    bool is_operable_with_complement()
+    {
+        return is_operable_with_complement(runtime::property<Operation, int>()());
+    }
+private:
+    virtual bool is_operable_with_complement(int operation_uuid)=0;
+};
+
 } } } // namespace boost::dataflow::blueprint
 
+namespace boost
+{
+    template<>
+    inline dataflow::blueprint::port* new_clone<dataflow::blueprint::port>
+        ( const dataflow::blueprint::port& r )
+    {
+        return r.clone();
+    }
+}
     
 
 #endif // BOOST_DATAFLOW_BLUEPRINT_GET_PORT_HPP
\ No newline at end of file

Modified: sandbox/SOC/2007/signals/boost/dataflow/blueprint/port_t.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/blueprint/port_t.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/blueprint/port_t.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -7,77 +7,162 @@
 #define BOOST_DATAFLOW_BLUEPRINT_PORT_T_HPP
 
 #include <boost/dataflow/blueprint/port.hpp>
+#include <boost/dataflow/blueprint/binary_operation_t.hpp>
 #include <boost/dataflow/support/port.hpp>
+#include <boost/call_traits.hpp>
+
+#include <typeinfo>
+
 
 namespace boost { namespace dataflow { namespace blueprint {
 
-namespace runtime
+template<typename T>
+struct initializer_type
 {
-    template<typename T, typename PropertyType>
-    struct property;
-    
-    template < >
-    struct property<ports::producer, const char *>
-    {
-        const char *operator()()
-        {
-            return "producer";
-        }
-    };
+    typedef
+        typename mpl::if_<
+            is_reference<T>,
+            T,
+            typename call_traits<T>::const_reference
+        >::type type;
+};
     
-    template < >
-    struct property<ports::consumer, const char *>
+template<typename Base, typename PortTraits, typename Port>
+class port_t_base : public Base
+{
+public:
+    port_t_base(typename initializer_type<Port>::type p)
+        : Base(
+            runtime_info(typename PortTraits::mechanism()),
+            runtime_info(typename PortTraits::category()),
+            runtime_info(typename PortTraits::concept()))
+        , p(p)
+    {}
+
+    void *get()
     {
-        const char *operator()()
-        {
-            return "consumer";
-        }
-    };
-    
-    template < >
-    struct property<ports::producer, int>
+        return &p;
+    }
+    virtual const std::type_info &port_type_info()
     {
-        int operator()()
-        {
-            return 0;
-        }
+        return typeid(Port);
     };
-    
-    template < >
-    struct property<ports::consumer, int>
+private:
+    Port p;
+};
+
+template<typename PortTraits, typename Port, typename Enable=void>
+class port_t : public port_t_base<port, PortTraits, Port>
+{
+    BOOST_MPL_ASSERT((is_same<Enable, void>));
+
+public:
+    port_t(typename call_traits<Port>::const_reference p)
+        : port_t_base<port, PortTraits, Port>(p)
+    {}
+    virtual port *clone() const
     {
-        int operator()()
-        {
-            return 1;
-        }
+        return new port_t(*this);
     };
-}
-
+};
 
 template<typename PortTraits, typename Port>
-class port_t : public port
+class port_t<
+    PortTraits,
+    Port,
+    typename enable_if<
+        is_complemented_port<
+            typename PortTraits::mechanism,
+            typename PortTraits::category,
+            Port
+        >
+    >::type >
+    : public port_t_base<complemented_port, PortTraits, Port>
 {
-    typedef typename PortTraits::mechanism::template runtime_connection<PortTraits>::type connection_type;
+
+    typedef
+        typename remove_reference<
+            typename get_port_result_type<
+                typename PortTraits::mechanism,
+                typename PortTraits::category,
+                Port
+            >::type
+        >::type get_port_type;
+        
+    typedef typename remove_reference<Port>::type port_type;
+
+    template<typename Operation>
+    struct operation_type
+    {
+        typedef
+            typename mpl::if_<
+                is_same<typename PortTraits::category, ports::producer>,
+                blueprint::binary_operation_t<
+                    Operation,
+                    typename PortTraits::mechanism,
+                    get_port_type,
+                    typename PortTraits::complement_port_type
+                >,
+                blueprint::binary_operation_t<
+                    Operation,
+                    typename PortTraits::mechanism,
+                    typename PortTraits::complement_port_type,
+                    get_port_type
+                >
+            >::type type;
+    };
+
 public:
-    port_t(Port p)
-        : port(port_category(
-            runtime::property<typename PortTraits::category, const char *>()(),
-            runtime::property<typename PortTraits::category, int>()()))
-        , p(p)
-        , c(new connection_type())
+    port_t(typename initializer_type<Port>::type p)
+        : port_t_base<complemented_port, PortTraits, Port>(p)
+        , c(new typename operation_type<operations::connect>::type())
+        , e(new typename operation_type<operations::extract>::type())
     {}
     
-    void *get()
+    virtual shared_ptr<binary_operation<operations::connect> > connector()
     {
-        return &p;
+        return c;
+    };
+    virtual shared_ptr<binary_operation<operations::extract> > extractor()
+    {
+        return e;
+    };
+    virtual const std::type_info &complement_type_info()
+    {
+        return typeid(typename PortTraits::complement_port_type);
     }
-    virtual shared_ptr<connection> connector()
+    virtual port *clone() const
     {
-        return c;
+        return new port_t(*this);
     };
+
 private:
-    Port p;
-    boost::shared_ptr<connection> c; 
+    virtual bool is_operable_with_complement(int operation_uuid)
+    {
+        typedef typename mpl::if_<
+            is_same<typename PortTraits::category, ports::producer>,
+            port_type,
+            typename PortTraits::complement_port_type
+        >::type producer_type;
+        typedef typename mpl::if_<
+            is_same<typename PortTraits::category, ports::producer>,
+            typename PortTraits::complement_port_type,
+            port_type
+        >::type consumer_type;
+
+        if(operation_uuid == runtime::property<operations::connect, int>()())
+            return dataflow::are_binary_operable<
+                operations::connect, typename PortTraits::mechanism, producer_type, consumer_type>::type::value; 
+        
+        if(operation_uuid == runtime::property<operations::extract, int>()())
+            return typename dataflow::are_binary_operable<
+                operations::extract, typename PortTraits::mechanism, producer_type, consumer_type>::type();
+        
+        return false;
+    };
+
+    boost::shared_ptr<binary_operation<operations::connect> > c; 
+    boost::shared_ptr<binary_operation<operations::extract> > e; 
 };
 
 } } } // namespace boost::dataflow::blueprint

Modified: sandbox/SOC/2007/signals/boost/dataflow/connection/port_map.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/connection/port_map.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/connection/port_map.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -68,8 +68,8 @@
     {
         template<typename Args> struct result;
         
-        template<typename F, typename KeyedPort, typename Key>
-        struct result<F(KeyedPort &, Key &)>
+        template<typename F, typename KeyedPort>
+        struct result<F(KeyedPort &)>
         {
             typedef typename boost::fusion::result_of::at_key<
                 typename KeyedPort::map_type,
@@ -77,9 +77,9 @@
             >::type type;
         };
 
-        template<typename KeyedPort, typename Key>
-        typename result<get_keyed_port_impl(KeyedPort &, Key &)>::type
-            operator()(KeyedPort &port, Key &)
+        template<typename KeyedPort>
+        typename result<get_keyed_port_impl(KeyedPort &)>::type
+            operator()(KeyedPort &port)
         {
             return boost::fusion::at_key<
                     KeyTag

Modified: sandbox/SOC/2007/signals/boost/dataflow/signals/component/storage.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/signals/component/storage.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/signals/component/storage.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -16,6 +16,7 @@
 #include <boost/fusion/container/map.hpp>
 #include <boost/dataflow/detail/make_ref.hpp>
 
+
 namespace boost { namespace signals {
 
     template<typename Signature,
@@ -28,11 +29,12 @@
 
 template<typename T>
 struct storage_component_traits
-    : public dataflow::reflective_component_traits<
-        dataflow::signals::mechanism,
+    : public dataflow::component_traits<
         mpl::vector<
             dataflow::signals::producer<T>, // outgoing signal
-            dataflow::signals::consumer<T> // incoming signal
+            dataflow::signals::consumer<T>, // incoming signal
+            dataflow::signals::extract_producer<T>, // outgoing extraction port
+            dataflow::signals::extract_consumer<T> // incoming extraction port
         > >
 {};
 
@@ -104,6 +106,13 @@
     
     typedef storage_component_traits<Signature> component_traits;
     
+    typedef mpl::vector<
+        typename boost::dataflow::signals::call_consumer,
+        typename boost::dataflow::signals::extract_producer<Signature>,
+        typename boost::dataflow::signals::extract_call_consumer
+         > port_traits;
+
+
     /**	Initializes the stored parameter values using the provided sequence.
         \param[in] seq Sequence from which the stored parameter sequence is initialized from.
         */
@@ -132,6 +141,11 @@
     {
         return send();
     }
+    typename base_type::signal_type::result_type call(const function<typename base_type::signature_type> &f)
+    {
+        boost::fusion::fused<function<typename base_type::signature_type> const &> fused_out(f);
+        return fused_out(base_type::modification.stored);
+    }
     /** \return A reference to the fusion vector of stored parameter values.
     */
     const storable_vector &stored_vector()
@@ -218,36 +232,50 @@
     template<typename T>
     struct get_component_port_impl<boost::signals::storage_component_traits<T> >
     {
-        template<typename FArgs> struct result;
-
-        template<typename F, typename Component>
-        struct result<F(Component &, boost::mpl::int_<0>)>
-        {
-            typedef signal<T> & type;
-        };
-        
-        template<typename F, typename Component>
-        struct result<F(Component &, boost::mpl::int_<1>)>
+        template<typename Component>
+        struct port_types
         {
-            typedef function<T> type;
+            typedef fusion::vector<signal<T> &, function<T>, Component &, function<T> > type;
         };
         
         template<typename Component>
-        signal<T> &
-        operator()(Component &component, boost::mpl::int_<0>)
+        typename port_types<Component>::type ports(Component &component)
         {
-            return component.get_proxied_producer();
+            return typename port_types<Component>::type(
+                component.get_proxied_producer(),
+                get_keyed_port<signals::producer<T> >(component),
+                component,
+                get_keyed_port<signals::extract_producer<T> >(component)
+                );
         }
+
+        template<typename FArgs> struct result;
+
+        template<typename F, typename Component, typename N>
+        struct result<F(Component &, N)>
+        {
+            typedef typename fusion::result_of::value_at<
+                typename port_types<Component>::type,
+                N>::type type;
+        };
         
-        template<typename Component>
-        function<T>
-        operator()(Component &component, boost::mpl::int_<1>)
+        template<typename Component, typename N>
+        typename result<get_component_port_impl(Component &, N)>::type
+        operator()(Component &component, N)
         {
-            return boost::signals::detail::bind_object<T, Component>()
-            (static_cast<typename boost::signals::detail::slot_type<T, Component>::type>(&Component::operator()), component);
+            return fusion::at<N>(ports(component));
         }
     };
     
+    template<typename T>
+    struct binary_operation_impl<operations::extract, signals::extract_producer<T>, signals::extract_consumer<T> >
+    {
+        template<typename Producer, typename Consumer>
+        void operator()(Producer &producer, Consumer &consumer)
+        {
+            producer.call(consumer);
+        }
+    };
 }
 
 } } // namespace boost::dataflow

Modified: sandbox/SOC/2007/signals/boost/dataflow/signals/connection/slot_selector.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/signals/connection/slot_selector.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/signals/connection/slot_selector.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -74,8 +74,8 @@
     {
         typedef const boost::function<Signature> result_type;
         
-        template<typename Consumer, typename Producer>
-        result_type operator()(Consumer &consumer, Producer &)
+        template<typename Consumer>
+        result_type operator()(Consumer &consumer)
         {
             return boost::signals::detail::bind_object<Signature, typename Consumer::class_type>()
             (static_cast<typename boost::signals::detail::slot_type<Signature, typename Consumer::class_type>::type>(consumer.func), consumer.object);

Deleted: sandbox/SOC/2007/signals/boost/dataflow/signals/runtime_support.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/signals/runtime_support.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
+++ (empty file)
@@ -1,31 +0,0 @@
-// Copyright Stjepan Rajko 2007. Use, modification and
-// distribution is subject to the Boost Software License, Version
-// 1.0. (See accompanying file LICENSE_1_0.txt or copy at
-// http://www.boost.org/LICENSE_1_0.txt)
-
-#ifndef SIGNAL_NETWORK_SIGNAL_RUNTIME_SUPPORT_HPP
-#define SIGNAL_NETWORK_SIGNAL_RUNTIME_SUPPORT_HPP
-
-#include <boost/dataflow/blueprint/connection_t.hpp>
-
-namespace boost { namespace dataflow {
-
-namespace signals {
-
-template<typename PortTraits>
-struct mechanism::runtime_connection<
-    PortTraits,
-    typename enable_if<is_same<mechanism, typename PortTraits::mechanism> >::type >
-{
-    typedef blueprint::connection_t<
-        mechanism,
-        boost::signal<typename PortTraits::signature_type> &,
-        boost::function<typename PortTraits::signature_type>
-    > type;
-};
-
-}
-
-} }
-
-#endif // SIGNAL_NETWORK_SIGNAL_RUNTIME_SUPPORT_HPP
\ No newline at end of file

Modified: sandbox/SOC/2007/signals/boost/dataflow/signals/support.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/signals/support.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/signals/support.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -15,15 +15,11 @@
 
 namespace signals {
 
-struct mechanism
-{
-    template<typename PortTraits, typename Enable=void>
-    struct runtime_connection;
-};
+struct mechanism {};
 
 template<typename T>
 struct producer
-    : public port_traits<mechanism, ports::producer, concepts::port>
+    : public complemented_port_traits<mechanism, ports::producer, boost::function<T> >
 {
     typedef T signature_type;
 };
@@ -39,20 +35,47 @@
     : public port_traits<mechanism, ports::consumer, concepts::keyed_port>
 {};
 
+    // mechanism used for data extraction
+    struct extract_mechanism {};
+    
+    template<typename T>
+    struct extract_producer
+    : public complemented_port_traits<extract_mechanism, ports::producer, boost::function<T> >
+    {
+        typedef T signature_type;
+    };
+    
+    template<typename T>
+    struct extract_consumer
+    : public port_traits<extract_mechanism, ports::consumer, concepts::port>
+    {
+        typedef T signature_type;
+    };
+    
+    struct extract_call_consumer
+    : public port_traits<extract_mechanism, ports::consumer, concepts::keyed_port>
+    {};
+
 } // namespace signals
 
 template<typename Signature, typename Combiner, typename Group, typename GroupCompare>
-struct port_traits_of<signals::mechanism, ports::producer, boost::signal<Signature, Combiner, Group, GroupCompare> >
+struct register_port_traits<signals::mechanism, ports::producer, boost::signal<Signature, Combiner, Group, GroupCompare> >
 {
     typedef signals::producer<Signature> type;
 };
 
 template<typename Signature>
-struct port_traits_of<signals::mechanism, ports::consumer, boost::function<Signature> >
+struct register_port_traits<signals::mechanism, ports::consumer, boost::function<Signature> >
 {
     typedef signals::consumer<Signature> type;
 };
 
+template<typename Signature>
+struct register_port_traits<signals::extract_mechanism, ports::consumer, boost::function<Signature> >
+{
+    typedef signals::extract_consumer<Signature> type;
+};
+
 namespace extension
 {
     template<typename Signature>
@@ -60,8 +83,21 @@
     {
         typedef const boost::function<Signature> result_type;
         
-        template<typename ConsumerPort, typename ProducerPort>
-        result_type operator()(ConsumerPort &consumer, ProducerPort &)
+        template<typename ConsumerPort>
+        result_type operator()(ConsumerPort &consumer)
+        {
+            return boost::signals::detail::bind_object<Signature, ConsumerPort>()
+            (static_cast<typename boost::signals::detail::slot_type<Signature, ConsumerPort>::type>(&ConsumerPort::operator()), consumer);
+        };
+    };
+    
+    template<typename Signature>
+    struct get_keyed_port_impl<signals::extract_call_consumer, signals::extract_producer<Signature> >
+    {
+        typedef const boost::function<Signature> result_type;
+        
+        template<typename ConsumerPort>
+        result_type operator()(ConsumerPort &consumer)
         {
             return boost::signals::detail::bind_object<Signature, ConsumerPort>()
             (static_cast<typename boost::signals::detail::slot_type<Signature, ConsumerPort>::type>(&ConsumerPort::operator()), consumer);
@@ -89,10 +125,16 @@
 #undef DATAFLOW_TEMPLATE_BINARY_OPERATION
 #undef DATAFLOW_TEMPLATE_MECHANISM
 
+#define DATAFLOW_TEMPLATE_MECHANISM boost::dataflow::signals::extract_mechanism
+#define DATAFLOW_TEMPLATE_BINARY_OPERATION extract
+#include <boost/dataflow/templates/binary_operation.hpp>
+#undef DATAFLOW_TEMPLATE_BINARY_OPERATION
+#undef DATAFLOW_TEMPLATE_MECHANISM
+
 template<typename Component>
 inline void invoke(Component &component)
 {
-    boost::dataflow::component_operation<boost::dataflow::operations::invoke, boost::dataflow::signals::mechanism>(component);
+    boost::dataflow::component_operation<boost::dataflow::operations::invoke>(component);
 }
 
 } } // namespace boost::phoenix

Modified: sandbox/SOC/2007/signals/boost/dataflow/support.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -8,10 +8,11 @@
 
 #include <boost/dataflow/support/port.hpp>
 #include <boost/dataflow/support/proxy_port.hpp>
+#include <boost/dataflow/support/complemented_port.hpp>
 #include <boost/dataflow/support/binary_operation.hpp>
 #include <boost/dataflow/support/keyed_port.hpp>
 #include <boost/dataflow/support/unary_operation.hpp>
-#include <boost/dataflow/support/reflective_component.hpp>
+#include <boost/dataflow/support/component.hpp>
 #include <boost/dataflow/support/component_operation.hpp>
 
 #endif // BOOST_DATAFLOW_SUPPORT_HPP

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/binary_operation.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/binary_operation.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/binary_operation.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -14,18 +14,16 @@
 
 namespace boost { namespace dataflow {
 
-namespace operations {
-    struct connect;
-    struct connect_only;
-    struct disconnect;
-    struct extract;
-}
-
 namespace extension
 {
     template<typename Operation, typename ProducerTag, typename ConsumerTag, typename Enable=void>
     struct binary_operation_impl
     {
+        struct detail
+        {
+            typedef void not_specialized;
+        };
+        
         template<typename Producer, typename Consumer>
         void operator()(Producer &, Consumer &)
         {
@@ -50,6 +48,53 @@
                get_port<Mechanism, ports::consumer>(consumer));
 }
 
+template<typename Operation, typename Mechanism, typename ProducerPort, typename ConsumerPort, typename Enable=void>
+struct are_binary_operable
+    : public mpl::false_
+{
+    BOOST_MPL_ASSERT((is_same<Enable, void>));
+};
+
+template<typename Operation, typename Mechanism, typename Producer, typename Consumer, typename Enable=void>
+struct specialized_binary_operation
+    : public mpl::true_
+{
+    BOOST_MPL_ASSERT((is_same<Enable, void>));
+};
+
+template<typename Operation, typename Mechanism, typename Producer, typename Consumer>
+struct specialized_binary_operation<
+    Operation,
+    Mechanism,
+    Producer,
+    Consumer,
+    typename detail::enable_if_defined<
+        typename extension::binary_operation_impl<
+            Operation,
+            typename port_traits_of<Mechanism, ports::producer, typename boost::remove_cv<Producer>::type>::type,
+            typename port_traits_of<Mechanism, ports::consumer, typename boost::remove_cv<Consumer>::type>::type
+        >::detail::not_specialized
+    >::type
+>
+    : public mpl::false_ {};
+
+template<typename Operation, typename Mechanism, typename Producer, typename Consumer>
+struct are_binary_operable<
+    Operation,
+    Mechanism,
+    Producer,
+    Consumer,
+    typename enable_if<
+        mpl::and_<
+            is_port<Mechanism, ports::producer, typename boost::remove_cv<Producer>::type>,
+            is_port<Mechanism, ports::consumer, typename boost::remove_cv<Consumer>::type>,
+            specialized_binary_operation<Operation,Mechanism,Producer,Consumer>
+        >
+    >::type
+>
+    : public mpl::true_ {};
+
+
 } } // namespace boost::dataflow
 
 #endif // BOOST_DATAFLOW_SUPPORT_BINARY_OPERATION_HPP

Added: sandbox/SOC/2007/signals/boost/dataflow/support/complemented_port.hpp
==============================================================================
--- (empty file)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/complemented_port.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -0,0 +1,64 @@
+// Copyright 2007 Stjepan Rajko.
+// Distributed under the Boost Software License, Version 1.0. (See
+// accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+
+#ifndef BOOST_DATAFLOW_SUPPORT_COMPLEMENT_PORT_HPP
+#define BOOST_DATAFLOW_SUPPORT_COMPLEMENT_PORT_HPP
+
+#include <boost/dataflow/support/port.hpp>
+
+namespace boost { namespace dataflow {
+
+/// Convenience class for PortTraits types.
+template<typename Mechanism, typename PortCategory, typename ComplementPort>
+struct complemented_port_traits
+{
+    typedef Mechanism mechanism;
+    typedef PortCategory category; 
+    typedef concepts::complemented_port concept;
+    typedef ComplementPort complement_port_type;
+};
+
+/// Boolean metafunction determining whether a type is a PortTraits.
+template<typename PortTraits, typename Enable=void>
+struct is_complemented_port_traits : public mpl::false_
+{};
+
+template<typename PortTraits>
+struct is_complemented_port_traits<PortTraits,
+    typename detail::enable_if_defined<
+        detail::all_of<
+            typename PortTraits::mechanism,
+            typename PortTraits::category,
+            typename PortTraits::concept,
+            typename PortTraits::complement_port_type
+        >
+    >::type>
+ : public mpl::true_
+{
+    BOOST_MPL_ASSERT(( is_port_category<typename PortTraits::category> ));
+};
+
+/// Boolean metafunction determining whether a type is a PortTraits.
+template<typename Mechanism, typename PortCategory, typename T, typename Enable=void>
+struct is_complemented_port : public mpl::false_
+{};
+
+template<typename Mechanism, typename PortCategory, typename T>
+struct is_complemented_port<Mechanism, PortCategory, T,
+        typename enable_if<
+            is_complemented_port_traits<
+                typename port_traits_of<
+                    Mechanism,
+                    PortCategory,
+                    typename utility::underlying_type<T>::type
+                >::type
+            >
+        >::type >
+    : public mpl::true_ {};
+
+
+} } // namespace boost::dataflow
+
+#endif // BOOST_DATAFLOW_SUPPORT_COMPLEMENT_PORT_HPP
\ No newline at end of file

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/component.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/component.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/component.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -14,46 +14,94 @@
 #include <boost/mpl/is_sequence.hpp>
 #include <boost/type_traits/is_same.hpp>
 #include <boost/type_traits/remove_cv.hpp>
+#include <boost/static_assert.hpp>
+#include <boost/utility/result_of.hpp>
 
 
 namespace boost { namespace dataflow {
 
-template<typename Mechanism>
+template<typename PortSequence>
 struct component_traits
 {
-    typedef Mechanism mechanism;
+    typedef PortSequence ports;
+    BOOST_MPL_ASSERT((mpl::is_sequence<PortSequence>));
 };
 
 /// Boolean metafunction determining whether a type is a ComponentTraits.
 template<typename ComponentTraits, typename Enable=void>
 struct is_component_traits : public mpl::false_
-{};
+{
+    BOOST_MPL_ASSERT((is_same<Enable, void>));
+};
 
 template<typename ComponentTraits>
 struct is_component_traits<ComponentTraits,
     typename detail::enable_if_defined<
-        typename ComponentTraits::mechanism
+        typename ComponentTraits::ports
     >::type>
  : public mpl::true_
 {};
 
 /// Metafunction returning the ComponentTraits of a type.
-template<typename Mechanism, typename T, typename Enable=void>
+template<typename T, typename Enable=void>
 struct component_traits_of
-{};
+{
+    BOOST_MPL_ASSERT((is_same<Enable, void>));
+};
 
 /// Specialization allowing intrusive specification of the ComponentTraits.
-template<typename Mechanism, typename T>
-struct component_traits_of<Mechanism, T,
-    typename enable_if<
-        is_same<Mechanism, typename T::component_traits::mechanism>
-    >::type
->
+template<typename T>
+struct component_traits_of<T>
 {
     typedef typename T::component_traits type;
     BOOST_MPL_ASSERT(( is_component_traits<type> ));
 };
 
+namespace extension {
+
+    template<typename ComponentTraits, typename Enable=void>
+    struct get_component_port_impl
+    {
+        BOOST_MPL_ASSERT((is_same<Enable, void>));
+
+        typedef void result_type;
+        
+        struct detail
+        {
+            typedef void not_specialized;
+        };
+
+        template<typename Component, typename T>
+        void operator()(Component &, T)
+        {
+            // Error: get_component_port_impl has not been
+            // implemented for ComponentTraits.
+            BOOST_STATIC_ASSERT(sizeof(Component)==0);
+        }
+    };
+    
+} // namespace extension
+
+template<typename T, typename Component>
+struct get_component_port_result_type
+{
+    typedef typename result_of<
+    extension::get_component_port_impl<
+        typename component_traits_of<Component>::type
+    >(Component &, T)>::type type;
+};
+
+template<typename T, typename Component>
+typename get_component_port_result_type<T, Component>::type
+get_component_port(Component &component)
+{
+    return
+        extension::get_component_port_impl<
+            typename component_traits_of<Component>::type
+        >()(component, T());
+}
+
+
 } } // namespace boost::dataflow
 
 #endif // BOOST_DATAFLOW_SUPPORT_COMPONENT_HPP

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/component_operation.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/component_operation.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/component_operation.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -27,6 +27,8 @@
     template<typename Operation, typename ComponentTraits, typename Enable=void>
     struct component_operation_impl
     {
+        BOOST_MPL_ASSERT((is_same<Enable, void>));
+
         struct detail
         {
             typedef void not_specialized;
@@ -42,30 +44,32 @@
     };
 }
 
-template<typename Operation, typename Mechanism, typename T, typename Enable=void>
+template<typename Operation, typename T, typename Enable=void>
 struct implements_component_operation
-    : public mpl::true_ {};
+    : public mpl::true_
+{
+    BOOST_MPL_ASSERT((is_same<Enable, void>));
+};
 
-template<typename Operation, typename Mechanism, typename T>
+template<typename Operation, typename T>
 struct implements_component_operation<
     Operation,
-    Mechanism,
     T,
     typename detail::enable_if_defined<
         typename extension::component_operation_impl<
             Operation,
-            typename component_traits_of<Mechanism, T>::type
+            typename component_traits_of<T>::type
         >::detail::not_specialized
     >::type
 >
     : public mpl::false_ {};
 
-template<typename Operation, typename Mechanism, typename Component>
+template<typename Operation, typename Component>
 void component_operation(Component &component)
 {
     extension::component_operation_impl<
         Operation,
-        typename component_traits_of<Mechanism, Component>::type
+        typename component_traits_of<Component>::type
     >()(component);
 }
 

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/keyed_port.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/keyed_port.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/keyed_port.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -15,11 +15,6 @@
 
 namespace boost { namespace dataflow {
 
-namespace concepts
-{
-    struct keyed_port;
-}
-
 namespace extension
 {
     template<typename KeyedPortTag, typename KeyPortTag>
@@ -28,7 +23,7 @@
         typedef void result_type;
 
         template<typename KeyedPort, typename Key>
-        void operator()(KeyedPort &, Key &)
+        void operator()(KeyedPort &)
         {
             // Error: get_keyed_port_impl has not been implemented
             // for KeyedPortTag and KeyPort.
@@ -36,17 +31,17 @@
         }
     };
 }
-    
-template<typename Mechanism, typename PortCategory, typename T1, typename T2>
-typename result_of<
+
+/*template<typename Mechanism, typename PortCategory, typename KeyPort, typename T>
+inline typename result_of<
     extension::get_keyed_port_impl<
         typename port_traits_of<
-            Mechanism, PortCategory, typename boost::remove_cv<T1>::type
+            Mechanism, PortCategory, typename boost::remove_cv<T>::type
         >::type,
         typename port_traits_of<
-            Mechanism, typename PortCategory::complement, typename boost::remove_cv<T2>::type
+            Mechanism, typename PortCategory::complement, typename boost::remove_cv<KeyPort>::type
         >::type
-    > (T1 &, T2 &)
+    > (T &)
 >::type
 get_keyed_port(T1 &t1, T2 &t2)
 {
@@ -58,6 +53,29 @@
             Mechanism, typename PortCategory::complement, typename boost::remove_cv<T2>::type
         >::type
     >()(t1, t2);
+}*/
+
+template<typename KeyPortTraits, typename KeyPort>
+inline typename result_of<
+    extension::get_keyed_port_impl<
+        typename port_traits_of<
+            typename KeyPortTraits::mechanism,
+            typename KeyPortTraits::category::complement,
+            typename boost::remove_cv<KeyPort>::type
+        >::type,
+        KeyPortTraits
+    > (KeyPort &)
+>::type
+get_keyed_port(KeyPort &p)
+{
+    return extension::get_keyed_port_impl<
+        typename port_traits_of<
+            typename KeyPortTraits::mechanism,
+            typename KeyPortTraits::category::complement,
+            typename boost::remove_cv<KeyPort>::type
+        >::type,
+        KeyPortTraits
+    >()(p);
 }
 
 namespace extension
@@ -72,7 +90,7 @@
         void operator()(Producer &producer, Consumer &consumer)
         {
             binary_operation<Operation, typename ProducerTag::mechanism>
-                (get_keyed_port<typename ProducerTag::mechanism, typename ProducerTag::category>(producer, consumer), consumer);
+                (get_keyed_port<ConsumerTag>(producer), consumer);
         }
     };
     
@@ -86,7 +104,7 @@
         void operator()(Producer &producer, Consumer &consumer)
         {
             binary_operation<Operation, typename ProducerTag::mechanism>
-                (producer, get_keyed_port<typename ProducerTag::mechanism, typename ConsumerTag::category>(consumer, producer));
+                (producer, get_keyed_port<ProducerTag>(consumer));
         }
     };
 

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/port.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/port.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/port.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -7,6 +7,7 @@
 #define BOOST_DATAFLOW_SUPPORT_PORT_HPP
 
 #include <boost/dataflow/detail/enable_if_defined.hpp>
+#include <boost/dataflow/support/tags.hpp>
 #include <boost/dataflow/utility/underlying_type.hpp>
 
 #include <boost/mpl/and.hpp>
@@ -15,27 +16,11 @@
 #include <boost/mpl/bool.hpp>
 #include <boost/mpl/is_sequence.hpp>
 #include <boost/type_traits/is_same.hpp>
+#include <boost/type_traits/add_reference.hpp>
 #include <boost/type_traits/remove_cv.hpp>
-#include <boost/utility/result_of.hpp>
 
-namespace boost { namespace dataflow {
-
-/// PortCategory types.
-namespace ports
-{
-    struct producer;
-    struct consumer;
 
-    struct producer
-    {
-        typedef consumer complement;
-    };
-
-    struct consumer
-    {
-        typedef producer complement;
-    };
-}
+namespace boost { namespace dataflow {
 
 /// Boolean metafunction determining whether a type is a PortCategory.
 template<typename T, typename Enable=void>
@@ -51,12 +36,6 @@
  : public mpl::true_
 {};
 
-namespace concepts
-{
-    /// Tag
-    struct port;
-}
-
 /// Convenience class for PortTraits types.
 template<typename Mechanism, typename PortCategory, typename PortConcept>
 struct port_traits
@@ -66,8 +45,12 @@
     typedef PortConcept concept;
 };
 
+namespace detail {
+    struct enable_guard;
+}
+
 /// Boolean metafunction determining whether a type is a PortTraits.
-template<typename PortTraits, typename Enable=void>
+template<typename PortTraits, typename Enable=detail::enable_guard>
 struct is_port_traits : public mpl::false_
 {};
 
@@ -78,7 +61,8 @@
             typename PortTraits::mechanism,
             typename PortTraits::category,
             typename PortTraits::concept
-        >
+        >,
+        detail::enable_guard
     >::type>
  : public mpl::true_
 {
@@ -113,6 +97,30 @@
 
 namespace boost { namespace dataflow {
 
+template<typename Mechanism, typename PortCategory, typename T, typename Enable=void>
+struct register_port_traits
+{};
+
+/// Specialization allowing non-intrusive specification of the PortTraits.
+template<typename Mechanism, typename PortCategory, typename T>
+struct port_traits_of<Mechanism, PortCategory, T,
+    typename detail::enable_if_defined<
+        typename register_port_traits<
+            Mechanism,
+            PortCategory,
+            typename remove_cv<T>::type
+        >::type
+    >::type
+>
+{
+    typedef typename register_port_traits<
+            Mechanism,
+            PortCategory,
+            typename remove_cv<T>::type
+        >::type type;
+    BOOST_MPL_ASSERT(( is_port_traits<type> ));
+};
+
 /// Boolean metafunction determining whether a type is a Port.
 template<typename Mechanism, typename PortCategory, typename T, typename Enable=void>
 struct is_port
@@ -121,11 +129,7 @@
 template<typename Mechanism, typename PortCategory, typename T>
 struct is_port<Mechanism, PortCategory, T,
         typename detail::enable_if_defined<
-            typename port_traits_of<
-                Mechanism,
-                PortCategory,
-                typename remove_cv<T>::type
-            >::type
+            typename port_traits_of<Mechanism,PortCategory,T>::type
         >::type >
     : public mpl::true_ {};
 
@@ -144,49 +148,14 @@
 namespace extension
 {
     template<typename Traits>
-    struct get_port_impl
-    {
-        template<typename Args> struct result;
-        
-        template<typename F, typename T>
-        struct result<F(T &) >
-        {
-            typedef T & type;
-        };
-        
-        template<typename T>
-        T & operator()(T &p)
-        {
-            BOOST_MPL_ASSERT(( is_port<typename Traits::mechanism, typename Traits::category, T> ));
-            return p;
-        }
-    };
+    struct get_port_impl;
 }
 
+// T might be a reference to a Port type
 template<typename Mechanism, typename PortCategory, typename T, typename Enable=void>
-struct get_port_result_type;
-/*{
-    typedef T & type;
-};*/
-
-template<typename Mechanism, typename PortCategory, typename T>
-struct get_port_result_type<
-    Mechanism,
-    PortCategory,
-    T,
-    typename disable_if<is_proxy_port<Mechanism, PortCategory, T> >::type>
+struct get_port_result_type
 {
-    typedef
-        typename result_of<
-            typename
-                extension::get_port_impl<
-                    typename port_traits_of<
-                        Mechanism,
-                        PortCategory,
-                        typename utility::underlying_type<T>::type
-                    >::type
-                >(T &)
-            >::type type;
+    typedef typename add_reference<T>::type type;
 };
 
 template<typename Mechanism, typename PortCategory, typename T>
@@ -196,9 +165,7 @@
 >::type
 get_port(T &p)
 {
-    return extension::get_port_impl<
-            typename port_traits_of<Mechanism, PortCategory, typename boost::remove_cv<T>::type >::type
-            >()(p);
+    return p;
 }
 
 } } // namespace boost::dataflow
@@ -207,7 +174,7 @@
 #define DATAFLOW_PORT_TRAITS(Type,PortTraits) \
 namespace boost { namespace dataflow { \
 template<> \
-struct port_traits_of< \
+struct register_port_traits< \
     PortTraits::mechanism, \
     PortTraits::category, \
     Type> \
@@ -222,7 +189,7 @@
 #define DATAFLOW_PORT_TRAITS_ENABLE_IF(Type,Cond,PortTraits) \
 namespace boost { namespace dataflow { \
 template<typename Type> \
-struct port_traits_of< \
+struct register_port_traits< \
     typename PortTraits::mechanism, \
     typename PortTraits::category, \
     Type, \

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/port_traits_sequence.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/port_traits_sequence.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/port_traits_sequence.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -33,7 +33,7 @@
 
 } }
 
-    #define BOOST_PP_ITERATION_PARAMS_1 (3, (0, 1, <boost/dataflow/support/port/detail/port_traits_sequence.hpp>))
+    #define BOOST_PP_ITERATION_PARAMS_1 (3, (0, 2, <boost/dataflow/support/port/detail/port_traits_sequence.hpp>))
     #include BOOST_PP_ITERATE()
 
     #endif

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/proxy_port_traits_sequence.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/proxy_port_traits_sequence.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/port/detail/proxy_port_traits_sequence.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -33,7 +33,7 @@
 
 } }
 
-    #define BOOST_PP_ITERATION_PARAMS_1 (3, (0, 1, <boost/dataflow/support/port/detail/proxy_port_traits_sequence.hpp>))
+    #define BOOST_PP_ITERATION_PARAMS_1 (3, (0, 2, <boost/dataflow/support/port/detail/proxy_port_traits_sequence.hpp>))
     #include BOOST_PP_ITERATE()
 
     #endif

Modified: sandbox/SOC/2007/signals/boost/dataflow/support/reflective_component.hpp
==============================================================================
--- sandbox/SOC/2007/signals/boost/dataflow/support/reflective_component.hpp	(original)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/reflective_component.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -8,8 +8,6 @@
 
 #include <boost/dataflow/support/component.hpp>
 
-#include <boost/static_assert.hpp>
-#include <boost/utility/result_of.hpp>
 
 
 namespace boost { namespace dataflow {

Added: sandbox/SOC/2007/signals/boost/dataflow/support/runtime.hpp
==============================================================================
--- (empty file)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/runtime.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -0,0 +1,71 @@
+// Copyright Stjepan Rajko 2007. Use, modification and
+// distribution is subject to the Boost Software License, Version
+// 1.0. (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+
+#ifndef DATAFLOW_RUNTIME_HPP
+#define DATAFLOW_RUNTIME_HPP
+
+#include <boost/dataflow/support/tags.hpp>
+
+#include <string>
+
+namespace boost { namespace dataflow {
+
+namespace runtime
+{
+    template<typename T, typename PropertyType>
+    struct property;
+} // namespace runtime
+
+class runtime_info
+{
+public:
+    template<typename T>
+    runtime_info(T)
+        : name_(runtime::property<T,const char *>()())
+        , uuid_(runtime::property<T,int>()())
+    {}
+
+    runtime_info(const std::string &name, int uuid)
+        : name_(name), uuid_(uuid)
+    {}
+
+    const char *name() const
+    {   return name_.c_str(); }
+    int uuid() const
+    {   return uuid_; }
+private:
+    std::string name_;
+    int uuid_;
+};
+
+} } // namespace boost::dataflow
+
+#define DATAFLOW_RUNTIME_PROPERTY(type,p_type,val)          \
+namespace boost { namespace dataflow { namespace runtime {  \
+    template<>                                              \
+    struct property<type, p_type>                           \
+    {                                                       \
+        p_type operator()()                                 \
+        {                                                   \
+            return val;                                     \
+        }                                                   \
+    };                                                      \
+} } }
+    
+DATAFLOW_RUNTIME_PROPERTY(ports::producer, const char *, "producer")
+DATAFLOW_RUNTIME_PROPERTY(ports::producer, int, 0)
+DATAFLOW_RUNTIME_PROPERTY(ports::consumer, const char *, "consumer")
+DATAFLOW_RUNTIME_PROPERTY(ports::consumer, int, 1)
+DATAFLOW_RUNTIME_PROPERTY(concepts::port, const char *, "port")
+DATAFLOW_RUNTIME_PROPERTY(concepts::port, int, 0)
+DATAFLOW_RUNTIME_PROPERTY(concepts::complemented_port, const char *, "complemented_port")
+DATAFLOW_RUNTIME_PROPERTY(concepts::complemented_port, int, 1)    
+
+DATAFLOW_RUNTIME_PROPERTY(operations::connect, const char *, "connect")
+DATAFLOW_RUNTIME_PROPERTY(operations::connect, int, 0)
+DATAFLOW_RUNTIME_PROPERTY(operations::extract, const char *, "extract")
+DATAFLOW_RUNTIME_PROPERTY(operations::extract, int, 1)
+
+#endif // DATAFLOW_RUNTIME_HPP
\ No newline at end of file

Added: sandbox/SOC/2007/signals/boost/dataflow/support/tags.hpp
==============================================================================
--- (empty file)
+++ sandbox/SOC/2007/signals/boost/dataflow/support/tags.hpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -0,0 +1,47 @@
+// Copyright 2007 Stjepan Rajko.
+// Distributed under the Boost Software License, Version 1.0. (See
+// accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+
+#ifndef BOOST_DATAFLOW_SUPPORT_TAGS_HPP
+#define BOOST_DATAFLOW_SUPPORT_TAGS_HPP
+
+
+namespace boost { namespace dataflow {
+
+/// PortCategory types.
+namespace ports
+{
+    struct producer;
+    struct consumer;
+
+    struct producer
+    {
+        typedef consumer complement;
+    };
+
+    struct consumer
+    {
+        typedef producer complement;
+    };
+}
+
+namespace concepts
+{
+    /// Tag
+    struct port {};
+    struct keyed_port {};
+    struct complemented_port {};
+}
+
+namespace operations {
+    struct connect;
+    struct connect_only;
+    struct disconnect;
+    struct extract;
+}
+
+} } // namespace boost::dataflow
+
+
+#endif // BOOST_DATAFLOW_SUPPORT_TAGS_HPP
\ No newline at end of file

Modified: sandbox/SOC/2007/signals/libs/dataflow/build/xcodeide/signal_network.xcodeproj/project.pbxproj
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/build/xcodeide/signal_network.xcodeproj/project.pbxproj	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/build/xcodeide/signal_network.xcodeproj/project.pbxproj	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -81,9 +81,18 @@
                 0800AC3A0C8CAAC300994538 /* Jamfile.v2 */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; name = Jamfile.v2; path = ../../../../Jamfile.v2; sourceTree = SOURCE_ROOT; };
                 0800AC3B0C8CAAC300994538 /* project-root.jam */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.jam; name = "project-root.jam"; path = "../../../../project-root.jam"; sourceTree = SOURCE_ROOT; };
                 0801B4370CE9488B00A7A8D1 /* operator.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = operator.hpp; sourceTree = "<group>"; };
+		0801C6980CF8F8E600820AC8 /* component.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = component.qbk; sourceTree = "<group>"; };
+		0801C6990CF8F8E600820AC8 /* port.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = port.qbk; sourceTree = "<group>"; };
+		0801C6A10CF8FA8700820AC8 /* concepts.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = concepts.qbk; sourceTree = "<group>"; };
+		0801C6A50CF8FAE500820AC8 /* binary_operable.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = binary_operable.qbk; sourceTree = "<group>"; };
+		0801C6AA0CF8FB7700820AC8 /* unary_operable.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = unary_operable.qbk; sourceTree = "<group>"; };
+		080612F30CF20A4A00F9DDF9 /* complemented_port.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = complemented_port.hpp; sourceTree = "<group>"; };
                 08061C2D0CBEE985002DC710 /* binary_operation.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = binary_operation.hpp; sourceTree = "<group>"; };
                 08061C980CBEF0C6002DC710 /* keyed_port.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = keyed_port.hpp; sourceTree = "<group>"; };
                 08061CC40CBEF3F7002DC710 /* port_map.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = port_map.hpp; sourceTree = "<group>"; };
+		0812D6370CF1283B0047236E /* binary_operation_t.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = binary_operation_t.hpp; sourceTree = "<group>"; };
+		0812D6380CF1283B0047236E /* binary_operation.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = binary_operation.hpp; sourceTree = "<group>"; };
+		0812D63C0CF140F30047236E /* component.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = component.hpp; sourceTree = "<group>"; };
                 08256FE60CEBDFEC003EC1B4 /* network.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = network.hpp; sourceTree = "<group>"; };
                 082761BE0C6037A90030E557 /* invocable.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = invocable.hpp; sourceTree = "<group>"; };
                 083FD3B90C62A4CB00EF3F6B /* concepts.qbk */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text; path = concepts.qbk; sourceTree = "<group>"; };
@@ -102,10 +111,7 @@
                 08C3EEA20C625AE30074AB9E /* simple_example.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = simple_example.cpp; sourceTree = "<group>"; };
                 08C675970C13A03E00D85379 /* Jamfile.v2 */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = Jamfile.v2; sourceTree = "<group>"; };
                 08DC14FC0C951C4800B96B2E /* Cone.cxx */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.cpp; path = Cone.cxx; sourceTree = "<group>"; };
-		08EF04520CEBF0EE002ABBBC /* connection.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = connection.hpp; sourceTree = "<group>"; };
-		08EF04590CEBF153002ABBBC /* connection_t.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = connection_t.hpp; sourceTree = "<group>"; };
                 08EF045E0CEBF1AD002ABBBC /* port_t.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = port_t.hpp; sourceTree = "<group>"; };
-		08EF05850CEBFDB3002ABBBC /* runtime_support.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = runtime_support.hpp; sourceTree = "<group>"; };
                 08EF9B220C5D506A00D4D206 /* applicator.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = applicator.hpp; sourceTree = "<group>"; };
                 08EF9B230C5D506A00D4D206 /* chain.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = chain.hpp; sourceTree = "<group>"; };
                 08EF9B240C5D506A00D4D206 /* conditional.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = conditional.hpp; sourceTree = "<group>"; };
@@ -142,9 +148,7 @@
                 08F0216B0C473AF000C0ED27 /* enable_if_defined.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = enable_if_defined.hpp; sourceTree = "<group>"; };
                 08F022C20C47556200C0ED27 /* group.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = group.hpp; sourceTree = "<group>"; };
                 08F022C70C47565600C0ED27 /* operators.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = operators.hpp; sourceTree = "<group>"; };
-		08F034B60CCBFA95009A4C8E /* port_concepts.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = port_concepts.qbk; sourceTree = "<group>"; };
                 08F077830C63F736003D448D /* components.qbk */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text; path = components.qbk; sourceTree = "<group>"; };
-		08F082020C1D591000687E1B /* introduction.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = introduction.qbk; sourceTree = "<group>"; };
                 08F082570C1DD53400687E1B /* components.qbk */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text; path = components.qbk; sourceTree = "<group>"; };
                 08F0825A0C1DD58500687E1B /* connections.qbk */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text; path = connections.qbk; sourceTree = "<group>"; };
                 08F1CD280CC55A5100EB5B4A /* port_traits_sequence.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = port_traits_sequence.hpp; sourceTree = "<group>"; };
@@ -171,7 +175,6 @@
                 08F264780CEA9DE800DA01C9 /* distributed_example.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = distributed_example.qbk; sourceTree = "<group>"; };
                 08F264790CEA9DE800DA01C9 /* gil_example.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = gil_example.qbk; sourceTree = "<group>"; };
                 08F2647A0CEA9DE800DA01C9 /* vtk_example.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = vtk_example.qbk; sourceTree = "<group>"; };
-		08F265450CEAC26F00DA01C9 /* component.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = component.hpp; sourceTree = "<group>"; };
                 08F26C8B0CBF1CBA00EDC3F6 /* test_port.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = test_port.cpp; sourceTree = "<group>"; };
                 08F26D630CBF2D4100EDC3F6 /* test_proxy_port.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = test_proxy_port.cpp; sourceTree = "<group>"; };
                 08F2C31B0CAD961F00F9100C /* vtk_dataflow_support.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = vtk_dataflow_support.hpp; sourceTree = "<group>"; };
@@ -184,12 +187,15 @@
                 08F37EDF0C57A4A700AC7FB8 /* static_function_call.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = static_function_call.hpp; sourceTree = "<group>"; };
                 08F3944C0CCEC35E00ED7978 /* binary_operation.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = binary_operation.hpp; sourceTree = "<group>"; };
                 08F3FE0C0CA0975100F0E144 /* common.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = common.hpp; sourceTree = "<group>"; };
+		08F40B2B0CEFF9BD00D20F30 /* introduction.qbk */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = introduction.qbk; sourceTree = "<group>"; };
+		08F417350CFA466000C10A54 /* runtime_support.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = runtime_support.hpp; sourceTree = "<group>"; };
+		08F4173A0CFA468D00C10A54 /* runtime.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = runtime.hpp; sourceTree = "<group>"; };
+		08F417460CFA486200C10A54 /* tags.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = tags.hpp; sourceTree = "<group>"; };
                 08F418080CBD69FE007E7F7A /* port.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = port.hpp; sourceTree = "<group>"; };
                 08F418AB0CBD7668007E7F7A /* proxy_port.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = proxy_port.hpp; sourceTree = "<group>"; };
                 08F448760CD5368000E128A8 /* simple_example_components.hpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.h; path = simple_example_components.hpp; sourceTree = "<group>"; };
                 08F4FBB80C56AFDF00EB271A /* producer_wrapper.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = producer_wrapper.hpp; sourceTree = "<group>"; };
                 08F4FC170C56C96300EB271A /* producer_container.hpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.h; path = producer_container.hpp; sourceTree = "<group>"; };
-		08F585BE0C5A7ED70086F4F4 /* concepts.qbk */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text; path = concepts.qbk; sourceTree = "<group>"; };
                 08F71D3E0CA3547C0010099E /* Jamfile.v2 */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = text; path = Jamfile.v2; sourceTree = "<group>"; };
                 08F71D3F0CA3547C0010099E /* test_bind_object.cpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.cpp; path = test_bind_object.cpp; sourceTree = "<group>"; };
                 08F71D400CA3547C0010099E /* test_branching.cpp */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.cpp.cpp; path = test_branching.cpp; sourceTree = "<group>"; };
@@ -248,6 +254,18 @@
                         path = VTK;
                         sourceTree = "<group>";
                 };
+		0801C6970CF8F8E600820AC8 /* concepts */ = {
+			isa = PBXGroup;
+			children = (
+				0801C6AA0CF8FB7700820AC8 /* unary_operable.qbk */,
+				0801C6A50CF8FAE500820AC8 /* binary_operable.qbk */,
+				0801C6A10CF8FA8700820AC8 /* concepts.qbk */,
+				0801C6980CF8F8E600820AC8 /* component.qbk */,
+				0801C6990CF8F8E600820AC8 /* port.qbk */,
+			);
+			path = concepts;
+			sourceTree = "<group>";
+		};
                 080DD7560C13908400EEB53D = {
                         isa = PBXGroup;
                         children = (
@@ -312,7 +330,7 @@
                                 08EF9B440C5D506A00D4D206 /* connection.hpp */,
                                 08EF9B450C5D506A00D4D206 /* detail */,
                                 08EF9B480C5D506A00D4D206 /* trait */,
-				08EF05850CEBFDB3002ABBBC /* runtime_support.hpp */,
+				08F417350CFA466000C10A54 /* runtime_support.hpp */,
                         );
                         path = signals;
                         sourceTree = "<group>";
@@ -407,6 +425,9 @@
                                 08F21FAD0CC6ABCF00DE649A /* component.hpp */,
                                 08F21FB90CC6B29600DE649A /* component_operation.hpp */,
                                 0844671B0CE7918C00B3CFDF /* reflective_component.hpp */,
+				080612F30CF20A4A00F9DDF9 /* complemented_port.hpp */,
+				08F4173A0CFA468D00C10A54 /* runtime.hpp */,
+				08F417460CFA486200C10A54 /* tags.hpp */,
                         );
                         path = support;
                         sourceTree = "<group>";
@@ -468,6 +489,7 @@
                 08F264770CEA9DE800DA01C9 /* introduction */ = {
                         isa = PBXGroup;
                         children = (
+				08F40B2B0CEFF9BD00D20F30 /* introduction.qbk */,
                                 08F264780CEA9DE800DA01C9 /* distributed_example.qbk */,
                                 08F264790CEA9DE800DA01C9 /* gil_example.qbk */,
                                 08F2647A0CEA9DE800DA01C9 /* vtk_example.qbk */,
@@ -479,13 +501,13 @@
                 08F265440CEAC22400DA01C9 /* blueprint */ = {
                         isa = PBXGroup;
                         children = (
-				08F265450CEAC26F00DA01C9 /* component.hpp */,
+				0812D63C0CF140F30047236E /* component.hpp */,
+				0812D6370CF1283B0047236E /* binary_operation_t.hpp */,
+				0812D6380CF1283B0047236E /* binary_operation.hpp */,
                                 08BD9AFB0CEB9D330069AFE2 /* get_port.hpp */,
                                 08BD9B090CEB9E3D0069AFE2 /* port.hpp */,
                                 08EF045E0CEBF1AD002ABBBC /* port_t.hpp */,
                                 08256FE60CEBDFEC003EC1B4 /* network.hpp */,
-				08EF04520CEBF0EE002ABBBC /* connection.hpp */,
-				08EF04590CEBF153002ABBBC /* connection_t.hpp */,
                         );
                         path = blueprint;
                         sourceTree = "<group>";
@@ -624,17 +646,15 @@
                 08FD5DE40C1BA60700F00877 /* doc */ = {
                         isa = PBXGroup;
                         children = (
+				0801C6970CF8F8E600820AC8 /* concepts */,
                                 08F3592C0CED1E9F00E2BBFB /* blueprint */,
                                 08F264770CEA9DE800DA01C9 /* introduction */,
-				08F034B60CCBFA95009A4C8E /* port_concepts.qbk */,
                                 083FD3C00C62A75100EF3F6B /* phoenix */,
                                 08FB7BEE0C6157AE00BD4EC2 /* signals */,
                                 08FD5E4D0C1BA60800F00877 /* Jamfile.v2 */,
                                 08FD5E4E0C1BA60800F00877 /* dataflow.qbk */,
-				08F082020C1D591000687E1B /* introduction.qbk */,
                                 08F36DFB0C41375B00E2F9A1 /* dataflow_table.xml */,
                                 08FA6A050C41E11800434913 /* rationale.qbk */,
-				08F585BE0C5A7ED70086F4F4 /* concepts.qbk */,
                                 08FB7BFE0C61597000BD4EC2 /* signals.qbk */,
                                 083FD3C60C62A7F600EF3F6B /* phoenix.qbk */,
                                 08F077830C63F736003D448D /* components.qbk */,

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/Jamfile.v2
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/Jamfile.v2	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/Jamfile.v2	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -14,6 +14,26 @@
 
 xml dataflow_xml : dataflow.qbk ;
 
+doxygen dataflow_blueprint_doxygen
+   :
+      [ glob ../../../boost/dataflow/blueprint/*.hpp ]
+   :
+        <doxygen:param>TAB_SIZE=4
+        <doxygen:param>EXAMPLE_PATH=../test
+        <doxygen:param>EXAMPLE_PATH=../example
+        <doxygen:param>STRIP_FROM_PATH=$(root)
+        <doxygen:param>STRIP_FROM_INC_PATH=$(root)
+        <doxygen:param>EXTRACT_ALL=NO
+        <doxygen:param>HIDE_UNDOC_MEMBERS=YES
+        <doxygen:param>INHERIT_DOCS=YES
+        <doxygen:param>EXTRACT_PRIVATE=NO
+        <doxygen:param>ENABLE_PREPROCESSING=YES
+        <doxygen:param>MACRO_EXPANSION=YES
+        <doxygen:param>SEARCH_INCLUDES=YES
+        <doxygen:param>INCLUDE_PATH=../../..
+        <doxygen:param>PREDEFINED=DOXYGEN_DOCS_ONLY
+   ;
+
 #doxygen dataflow_doxygen
 #   :
 #      [ glob ../../../boost/dataflow/support.hpp ]
@@ -41,6 +61,7 @@
 boostbook standalone
    :
       dataflow_xml
+      dataflow_blueprint_doxygen
 #      dataflow_doxygen
     :
         # pull in the online .css and images

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/blueprint/blueprint.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/blueprint/blueprint.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/blueprint/blueprint.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -1,12 +1,13 @@
 [section:blueprint Dataflow.Blueprint]
 
-The current focus of the Dataflow library are mechanisms in which the
-dataflow network is stored in the individual components - i.e., there
-is no global picture of the network available through the library.
-
-The [DataflowBlueprint] layer addresses this shortcoming by
-providing generic components that provide this "big picture"
-of a dataflow network.  A blueprint component corresponds to an actual
+The [DataflowBlueprint] layer
+provides generic components that can hold the "big picture"
+of a dataflow network.  This is particularly useful for those dataflow
+frameworks (such as [DataflowSignals] where the dataflow network is stored in
+the individual components - i.e., there
+is no global picture of the network available.
+
+A blueprint component corresponds to an actual
 component - but whereas the actual component takes care of the work, the
 blueprint component provides a run-time polymorphic interface which can be
 embedded in a BGL graph. A dataflow network blueprint uses such a graph
@@ -17,12 +18,14 @@
 future work section].
 
 The [DataflowBlueprint] layer is built on top of the Dataflow library 
-[concepts].  Hence, it can be used with any mechanism for which a Dataflow
-support layer has been implemented.
+[concepts].  Hence, it can be used with any dataflow framework for which a
+Dataflow support layer has been implemented.
 
 [warning The [DataflowBlueprint] layer development has only started, and
-the current implementation is very rough.  There is no documentation,
+the current implementation is very rough.  There is no detailed documentation,
 but the provided [link dataflow.introduction.examples.blueprint example]
 provides some insight into its usability.]
 
+[xinclude ../dataflow_blueprint_doxygen.xml]
+
 [endsect]
\ No newline at end of file

Deleted: sandbox/SOC/2007/signals/libs/dataflow/doc/concepts.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/concepts.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
+++ (empty file)
@@ -1,487 +0,0 @@
-[section Concepts]
-
-[/To explore generic dataflow in C++, let us begin by examining where the flow of
-data happens in C++.  Rather informally, we can divide things as follows:
-
-* on one hand, there is data (variables, objects, etc...)
-* on the other, there are computational elements (functions, methods, etc...)
-
-Data can then be processed by the computational
-elements by applying the elements to the data in some appropriate way.
-There are several ways of providing data to the computational elements:
-
-* by placing it in a location where the computational element will read it
-* by passing it as a parameter in a call
-* (a combination of the above) by passing the location of the data as a
-parameter in a call
-
-Similarly, there are several ways of getting data out of a computational element:
-
-* the element makes a function call that carries the data as a parameter
-* the element places a value somewhere where it can be read
-* the element returns it as a return value
-
-With the above in mind, let's informally introduce a few concepts related to dataflow
-programming:]
-
-[heading Mechanisms]
-
-There are many different environments that offer dataflow-related functionality.
-For example, [BoostSignals] offers transfer of data through function calls,
-while [VTK] offers a number of classes which are meant to be connected in
-a pipline (e.g., starting with the data source, manipulating it, and
-finally displaying it on the screen).
-
-[BoostSignals] and [VTK] are examples of different /mechanisms/ - particular
-environments each offering their own, independent way of doing dataflow.
-In the Dataflow library, everything is keyed through a mechanism type
-tag, allowing different mechanisms to be specified independently, and
-allowing a single component to support muliple mechanisms.
-
-[heading Ports]
-
-The fundamental point of data production or consumption is called a /port/.
-Two complementary ports that produce / consume the same type of data (using
-the same type of mechanism) can typically be connected/disconnected, or data
-can be extracted from one port to another.
-
-Depending on the data-transport mechanism used, a producer port could be anything
-that produces / provides data:  a POD variable, an object of a class type, or
-a function that returns a value.  Similarly, a consumer port could be anything
-that consumes data - a function that takes an argument, a functor, etc.
-
-Ports are captured more formally by the [PortConcept] concept.
-
-[heading Components]
-
-A /component/ is the fundamental data processing element of a dataflow
-network.  It can have multiple ports, for example a video filter component
-might have one consumer port (consuming video to be processed) and one
-producer port (producing filtered video).
-
-Typically, a component is embedded in a class, and the different [PortConcept]s
-are accessible either through the class directly, or through its member
-functions and variables.
-
-The Dataflow library also offers a [ComponentConcept] concept, which is
-intented to provide compile-time introspection and other operations.
-
-[heading Proxies]
-
-It is often the case that a port delegates its [PortConcept]
-functionality to some other element.  For example, a
-class that is a [DataflowSignals] component might delegate its
-[ProducerPortConcept] functionality to a member boost::signal.  It can
-do so by declaring itself a [ProxyProducerPortConcept] for the boost::signal.
-
-[heading Port Operations]
-
-To establish a flow of data in a dataflow program, we typically /connect/
-producers and consumers using some type of /connection/. In C++, this is usually
-done through a pointer-like mechanism.  For example, a boost::signal can be used
-by a producer to dissiminate data to multiple consumers which have been
-connected to the signal. Or, a consumer class might have a pointer to a variable
-which it collects data from.
-
-Operations between two ports such as /connect/, /connect_only/, /disconnect/,
-and /extract/ are captured by the [BinaryOperable] concept.  Operations
-on a single port such as /disconnect_all/ are covered by the [UnaryOperableConcept]
-concept.
-
-[/
-[heading Push and pull]
-
-Components can be further categorized according to where the connection lies,
-and what it points to.  If the producer contains the connection(s) which point
-to the consumer(s) (say, a `boost::signal<void (int)>`), the producer is called a
-/push producer/.  If the consumer contains the connection(s) which point to the
-producer(s), the consumer is called a /pull consumer/.  A connection
-between a push producer and a (non-pull) consumer is a /push connection/,
-and a connection between a pull consumer and a (non-push) producer is a
-/pull connection/.
-
-Sometimes things get a little fuzzy - for example, a function
-call can be used to transmit data through the arguments from the caller to the
-callee.  However, the callee can transmit data back to the caller by returning
-it.  Hence, an object which contains a boost::signal could be both a push
-producer (which sends data through the signal argument) and a pull consumer
-(which receives data through the signal return type).  If both directions
-are being used to transmit data, a connection like this is called a /push and
-pull connection/.
-
-It is also possible that the producer points to the consumer and vice versa.
-In this case, the connection is called a /bidirectional connection/.]
-
-[heading Invocation]
-
-[/Another important thing to note is that there is a separation between providing
-the data to a component, and invoking the component.  In some cases, the two
-happen simultaneously (when the data is passed and returned via a function
-call), while in others invoking the computational element can happen
-separately from providing the data (at least from a modeling perspective).
-An example of the latter is a consumer which uses data stored in
-a particular location. We can place the data in that location much before
-invoking the consumer.]
-
-We will call /invoking/ a component (producer or consumer) the action of
-causing it to consume data from connected producers, and producing data
-for connected consumers.
-
-Invocation is captured more formally by the [InvocableConcept] concept.
-
-
-
-[section Mechanism]
-
-[note The Mechanism concept currently has no requirements.]
-
-A Mechanism type is used to specify the mechanism when specializing or invoking
-Dataflow templates.  Each mechanism therefore has a corresponding
-type tag.
-
-[heading Examples]
-
-The following code declares the [VTK] mechanism tag - it is a part of
-the [vtk_example example showing how to provide a VTK support layer].
-
-[vtk_mechanism]
-
-[endsect][/mechanism]
-
-[include port_concepts.qbk]
-
-[section:binaryoperable BinaryOperable (Connectable, OnlyConnectable, Disconnectable, Extractable) ]
-
-A [ProducerPortConcept] `P` and [ConsumerPortConcept] `C` are /BinaryOperable/
-for a binary operation `O`, and mechanism `M`, if the implementation of
-the binary operation `O` has been specialized for `M`, `P`, and `C`.
-
-In this case,
-
-* If `O` is operations::connect, `P` and `C` are [ConnectableConcept]
-* If `O` is operations::connect_only, `P` and `C` are [OnlyConnectableConcept]
-* If `O` is operations::disconnect, `P` and `C` are [DisconnectableConcept]
-* If `O` is operations::extract, `P` and `C` are [ExtractableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [ProducerPortConcept] type.]]
-    [[C_C] [A [ConsumerPortConcept] [ConnectableConcept] with `P`]]
-    [[C_O] [A [ConsumerPortConcept] [OnlyConnectableConcept] with `P`]]
-    [[C_D] [A [ConsumerPortConcept] [DisconnectableConcept] with `P`]]
-    [[C_E] [A [ConsumerPortConcept] [ExtractableConcept] with `P`]]
-    [[p] [An object of type P.]]
-    [[c_c] [An object of type C_C.]]
-    [[c_o] [An object of type C_O.]]
-    [[c_d] [An object of type C_D.]]
-    [[c_e] [An object of type C_E.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Connect]
-        [`binary_operation<operations::connect, M>(p,c_c)`]
-        [void]
-        [
-            Creates a lasting connection between the `p` and `c`.
-        ]
-    ]
-    [
-        [OnlyConnect]
-        [`binary_operation<operations::connect_only, M>(p,c_o)`]
-        [void]
-        [
-            Discards any lasting connections stored by `p` or `c`,
-            and creates a lasting connection between `p` and `c`.
-            Note that `p` or `c` could still be connected to other ports,
-            as long as these connections are not stored in `p` or `c`.
-        ]
-    ]
-    [
-        [Disconnect]
-        [`binary_operation<operations::disconnect, M>(p,c_d)`]
-        [void]
-        [
-            Discards any existing connection between `p` and `c`.
-        ]
-    ]
-    [
-        [Extract]
-        [`binary_operation<operations::extract, M>(p,c_e)`]
-        [void]
-        [
-            Perfoms a one time transfer of data from `p` to `c`.
-        ]
-    ]
-]
-
-[endsect][/binaryoperable]
-
-[section:unaryoperable UnnaryOperable (AllDisconnectable) ]
-
-A [PortConcept] `P` is /UnnaryOperable/
-for a unary operation `O`, and mechanism `M`, if the implementation of
-the unnary operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::disconnect_all, `P` is [AllDisconnectable]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [PortConcept] type.]]
-    [[p] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Disconnect All]
-        [`unnary_operation<operations::disconnect_all, M>(p)`]
-        [void]
-        [
-            Destroys any connections stored by `p`.  
-        ]
-    ]
-]
-
-[endsect][/unaryoperable]
-
-[section ComponentTraits]
-
-A ['[ComponentTraitsConcept]] specifies the traits of a [ComponentConcept].
-
-[heading Notation]
-[variablelist
-    [[CT] [A ComponentTraits type.]]
-    [[C] [A [ComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types.]
-        [[PortTraitsConcept] of exposed [PortConcept]s.]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/componenttraits]
-
-[section ReflectiveComponentTraits]
-
-A ['[ReflectiveComponentTraitsConcept]] specifies the traits of a [ReflectiveComponentConcept].
-
-[heading Refinement of]
-
-* [ComponentTraitsConcept]
-
-[heading Notation]
-[variablelist
-    [[CT] [A ReflectiveComponentTraits type.]]
-    [[C] [A [ReflectiveComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types]
-        [
-            An enumeration of the [PortTraitsConcept] of the exposed
-            [PortConcept]s.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/reflective_component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/reflectivecomponenttraits]
-
-[section Component]
-
-[note The Component concept is not fully fleshed out.  It lacks any
-functionality related to getting access to any [PortConcept] that is
-a part of the component.]
-
-A type `C` is a ['[ComponentConcept]] for a mechanism `M`
-if it specifies a [ComponentTraitsConcept] for that mechanism.
-
-[heading Refinements]
-
-* [ReflectiveComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A Component type.]]
-    [[M] [A [MechanismConcept] type.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ComponentTraitsConcept] type]
-        [
-            The [ComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the Component
-            concept.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-[section ReflectiveComponent]
-
-A [ComponentConcept] `C` for a mechanism `M` is a ['[ReflectiveComponentConcept]] 
-if's [ComponentTraitsConcept] is a [ReflectiveComponentTraitsConcept], and it
-specializes the `get_component_port_impl` implementation to provide access
-to it's ports.
-
-[heading Refinement of]
-
-* [ComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A ReflectiveComponent type.]]
-    [[M] [A [MechanismConcept] type.]]
-    [[I] [An MPL Integral Constant in the range 0, n of ports exposed by C.]]
-    [[c] [An object of type C.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ReflectiveComponentTraitsConcept] type]
-        [
-            The [ReflectiveComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsReflectiveComponent Trait]
-        [`is_reflective_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the ReflectiveComponent
-            concept.
-        ]
-    ]
-    [
-        [ GetComponentPort ]
-        [`get_component_port<M, I>(c)`]
-        []
-        [
-            Returns the I'th [PortConcept] exposed by `C`
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-
-[section:componentoperable ComponentOperable (Invocable) ]
-
-A [ComponentConcept] `P` is /ComponentOperable/
-for a component operation `O`, and mechanism `M`, if the implementation of
-the component operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::invoke, `P` is [Invocable]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A [ComponentConcept] type.]]
-    [[c] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Invoke]
-        [`component_operation<operations::invoke, M>(p)`]
-        [Any type]
-        [
-            Invokes `c` - this typically causes a component to consume its
-            input data and produce its output data as appropriate.  
-        ]
-    ]
-]
-
-[endsect][/componentoperable]
-
-[endsect][/concepts]

Copied: sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/binary_operable.qbk (from r41347, /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk)
==============================================================================
--- /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/binary_operable.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -1,155 +1,3 @@
-[section Concepts]
-
-[/To explore generic dataflow in C++, let us begin by examining where the flow of
-data happens in C++.  Rather informally, we can divide things as follows:
-
-* on one hand, there is data (variables, objects, etc...)
-* on the other, there are computational elements (functions, methods, etc...)
-
-Data can then be processed by the computational
-elements by applying the elements to the data in some appropriate way.
-There are several ways of providing data to the computational elements:
-
-* by placing it in a location where the computational element will read it
-* by passing it as a parameter in a call
-* (a combination of the above) by passing the location of the data as a
-parameter in a call
-
-Similarly, there are several ways of getting data out of a computational element:
-
-* the element makes a function call that carries the data as a parameter
-* the element places a value somewhere where it can be read
-* the element returns it as a return value
-
-With the above in mind, let's informally introduce a few concepts related to dataflow
-programming:]
-
-[heading Mechanisms]
-
-There are many different environments that offer dataflow-related functionality.
-For example, [BoostSignals] offers transfer of data through function calls,
-while [VTK] offers a number of classes which are meant to be connected in
-a pipline (e.g., starting with the data source, manipulating it, and
-finally displaying it on the screen).
-
-[BoostSignals] and [VTK] are examples of different /mechanisms/ - particular
-environments each offering their own, independent way of doing dataflow.
-In the Dataflow library, everything is keyed through a mechanism type
-tag, allowing different mechanisms to be specified independently, and
-allowing a single component to support muliple mechanisms.
-
-[heading Ports]
-
-The fundamental point of data production or consumption is called a /port/.
-Two complementary ports that produce / consume the same type of data (using
-the same type of mechanism) can typically be connected/disconnected, or data
-can be extracted from one port to another.
-
-Depending on the data-transport mechanism used, a producer port could be anything
-that produces / provides data:  a POD variable, an object of a class type, or
-a function that returns a value.  Similarly, a consumer port could be anything
-that consumes data - a function that takes an argument, a functor, etc.
-
-Ports are captured more formally by the [PortConcept] concept.
-
-[heading Components]
-
-A /component/ is the fundamental data processing element of a dataflow
-network.  It can have multiple ports, for example a video filter component
-might have one consumer port (consuming video to be processed) and one
-producer port (producing filtered video).
-
-Typically, a component is embedded in a class, and the different [PortConcept]s
-are accessible either through the class directly, or through its member
-functions and variables.
-
-The Dataflow library also offers a [ComponentConcept] concept, which is
-intented to provide compile-time introspection and other operations.
-
-[heading Proxies]
-
-It is often the case that a port delegates its [PortConcept]
-functionality to some other element.  For example, a
-class that is a [DataflowSignals] component might delegate its
-[ProducerPortConcept] functionality to a member boost::signal.  It can
-do so by declaring itself a [ProxyProducerPortConcept] for the boost::signal.
-
-[heading Port Operations]
-
-To establish a flow of data in a dataflow program, we typically /connect/
-producers and consumers using some type of /connection/. In C++, this is usually
-done through a pointer-like mechanism.  For example, a boost::signal can be used
-by a producer to dissiminate data to multiple consumers which have been
-connected to the signal. Or, a consumer class might have a pointer to a variable
-which it collects data from.
-
-Operations between two ports such as /connect/, /connect_only/, /disconnect/,
-and /extract/ are captured by the [BinaryOperableConcept] concept.  Operations
-on a single port such as /disconnect_all/ are covered by the [UnaryOperableConcept]
-concept.
-
-[/
-[heading Push and pull]
-
-Components can be further categorized according to where the connection lies,
-and what it points to.  If the producer contains the connection(s) which point
-to the consumer(s) (say, a `boost::signal<void (int)>`), the producer is called a
-/push producer/.  If the consumer contains the connection(s) which point to the
-producer(s), the consumer is called a /pull consumer/.  A connection
-between a push producer and a (non-pull) consumer is a /push connection/,
-and a connection between a pull consumer and a (non-push) producer is a
-/pull connection/.
-
-Sometimes things get a little fuzzy - for example, a function
-call can be used to transmit data through the arguments from the caller to the
-callee.  However, the callee can transmit data back to the caller by returning
-it.  Hence, an object which contains a boost::signal could be both a push
-producer (which sends data through the signal argument) and a pull consumer
-(which receives data through the signal return type).  If both directions
-are being used to transmit data, a connection like this is called a /push and
-pull connection/.
-
-It is also possible that the producer points to the consumer and vice versa.
-In this case, the connection is called a /bidirectional connection/.]
-
-[heading Invocation]
-
-[/Another important thing to note is that there is a separation between providing
-the data to a component, and invoking the component.  In some cases, the two
-happen simultaneously (when the data is passed and returned via a function
-call), while in others invoking the computational element can happen
-separately from providing the data (at least from a modeling perspective).
-An example of the latter is a consumer which uses data stored in
-a particular location. We can place the data in that location much before
-invoking the consumer.]
-
-We will call /invoking/ a component (producer or consumer) the action of
-causing it to consume data from connected producers, and producing data
-for connected consumers.
-
-Invocation is captured more formally by the [InvocableConcept] concept.
-
-
-
-[section Mechanism]
-
-[note The Mechanism concept currently has no requirements.]
-
-A Mechanism type is used to specify the mechanism when specializing or invoking
-Dataflow templates.  Each mechanism therefore has a corresponding
-type tag.
-
-[heading Examples]
-
-The following code declares the [VTK] mechanism tag - it is a part of
-the [vtk_example example showing how to provide a VTK support layer].
-
-[vtk_mechanism]
-
-[endsect][/mechanism]
-
-[include port_concepts.qbk]
-
 [section:binaryoperable BinaryOperable (Connectable, OnlyConnectable, Disconnectable, Extractable) ]
 
 A [ProducerPortConcept] `P` and [ConsumerPortConcept] `C` are /BinaryOperable/
@@ -220,268 +68,3 @@
 ]
 
 [endsect][/binaryoperable]
-
-[section:unaryoperable UnnaryOperable (AllDisconnectable) ]
-
-A [PortConcept] `P` is /UnnaryOperable/
-for a unary operation `O`, and mechanism `M`, if the implementation of
-the unnary operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::disconnect_all, `P` is [AllDisconnectable]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [PortConcept] type.]]
-    [[p] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Disconnect All]
-        [`unnary_operation<operations::disconnect_all, M>(p)`]
-        [void]
-        [
-            Destroys any connections stored by `p`.  
-        ]
-    ]
-]
-
-[endsect][/unaryoperable]
-
-[section ComponentTraits]
-
-A ['[ComponentTraitsConcept]] specifies the traits of a [ComponentConcept].
-
-[heading Notation]
-[variablelist
-    [[CT] [A ComponentTraits type.]]
-    [[C] [A [ComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types.]
-        [[PortTraitsConcept] of exposed [PortConcept]s.]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/componenttraits]
-
-[section ReflectiveComponentTraits]
-
-A ['[ReflectiveComponentTraitsConcept]] specifies the traits of a [ReflectiveComponentConcept].
-
-[heading Refinement of]
-
-* [ComponentTraitsConcept]
-
-[heading Notation]
-[variablelist
-    [[CT] [A ReflectiveComponentTraits type.]]
-    [[C] [A [ReflectiveComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types]
-        [
-            An enumeration of the [PortTraitsConcept] of the exposed
-            [PortConcept]s.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/reflectivecomponenttraits]
-
-[section Component]
-
-[note The Component concept is not fully fleshed out.  It lacks any
-functionality related to getting access to any [PortConcept] that is
-a part of the component.]
-
-A type `C` is a ['[ComponentConcept]] for a mechanism `M`
-if it specifies a [ComponentTraitsConcept] for that mechanism.
-
-[heading Refinements]
-
-* [ReflectiveComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A Component type.]]
-    [[M] [A [MechanismConcept] type.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ComponentTraitsConcept] type]
-        [
-            The [ComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the Component
-            concept.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-[section ReflectiveComponent]
-
-A [ComponentConcept] `C` for a mechanism `M` is a ['[ReflectiveComponentConcept]] 
-if's [ComponentTraitsConcept] is a [ReflectiveComponentTraitsConcept], and it
-specializes the `get_component_port_impl` implementation to provide access
-to it's ports.
-
-[heading Refinement of]
-
-* [ComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A ReflectiveComponent type.]]
-    [[M] [A [MechanismConcept] type.]]
-    [[I] [An MPL Integral Constant in the range 0, n of ports exposed by C.]]
-    [[c] [An object of type C.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ReflectiveComponentTraitsConcept] type]
-        [
-            The [ReflectiveComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsReflectiveComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the ReflectiveComponent
-            concept.
-        ]
-    ]
-    [
-        [ GetComponentPort ]
-        [`get_component_port<M, I>(c)`]
-        []
-        [
-            Returns the I'th [PortConcept] exposed by `C`
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-
-[section:componentoperable ComponentOperable (Invocable) ]
-
-A [ComponentConcept] `P` is /ComponentOperable/
-for a component operation `O`, and mechanism `M`, if the implementation of
-the component operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::invoke, `P` is [InvocableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A [ComponentConcept] type.]]
-    [[c] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Invoke]
-        [`component_operation<operations::invoke, M>(p)`]
-        [Any type]
-        [
-            Invokes `c` - this typically causes a component to consume its
-            input data and produce its output data as appropriate.  
-        ]
-    ]
-]
-
-[endsect][/componentoperable]
-
-[endsect][/concepts]

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -1,362 +1,28 @@
-[section Concepts]
 
-[/To explore generic dataflow in C++, let us begin by examining where the flow of
-data happens in C++.  Rather informally, we can divide things as follows:
+[section:component Component, ComponentTraits]
 
-* on one hand, there is data (variables, objects, etc...)
-* on the other, there are computational elements (functions, methods, etc...)
+A ['[ComponentConcept]] is the fundamental data processing element.  It can
+have a number of [PortConcept]s, and can also be [InvocableConcept].
 
-Data can then be processed by the computational
-elements by applying the elements to the data in some appropriate way.
-There are several ways of providing data to the computational elements:
-
-* by placing it in a location where the computational element will read it
-* by passing it as a parameter in a call
-* (a combination of the above) by passing the location of the data as a
-parameter in a call
-
-Similarly, there are several ways of getting data out of a computational element:
-
-* the element makes a function call that carries the data as a parameter
-* the element places a value somewhere where it can be read
-* the element returns it as a return value
-
-With the above in mind, let's informally introduce a few concepts related to dataflow
-programming:]
-
-[heading Mechanisms]
-
-There are many different environments that offer dataflow-related functionality.
-For example, [BoostSignals] offers transfer of data through function calls,
-while [VTK] offers a number of classes which are meant to be connected in
-a pipline (e.g., starting with the data source, manipulating it, and
-finally displaying it on the screen).
-
-[BoostSignals] and [VTK] are examples of different /mechanisms/ - particular
-environments each offering their own, independent way of doing dataflow.
-In the Dataflow library, everything is keyed through a mechanism type
-tag, allowing different mechanisms to be specified independently, and
-allowing a single component to support muliple mechanisms.
-
-[heading Ports]
-
-The fundamental point of data production or consumption is called a /port/.
-Two complementary ports that produce / consume the same type of data (using
-the same type of mechanism) can typically be connected/disconnected, or data
-can be extracted from one port to another.
-
-Depending on the data-transport mechanism used, a producer port could be anything
-that produces / provides data:  a POD variable, an object of a class type, or
-a function that returns a value.  Similarly, a consumer port could be anything
-that consumes data - a function that takes an argument, a functor, etc.
-
-Ports are captured more formally by the [PortConcept] concept.
-
-[heading Components]
-
-A /component/ is the fundamental data processing element of a dataflow
-network.  It can have multiple ports, for example a video filter component
-might have one consumer port (consuming video to be processed) and one
-producer port (producing filtered video).
-
-Typically, a component is embedded in a class, and the different [PortConcept]s
-are accessible either through the class directly, or through its member
-functions and variables.
-
-The Dataflow library also offers a [ComponentConcept] concept, which is
-intented to provide compile-time introspection and other operations.
-
-[heading Proxies]
-
-It is often the case that a port delegates its [PortConcept]
-functionality to some other element.  For example, a
-class that is a [DataflowSignals] component might delegate its
-[ProducerPortConcept] functionality to a member boost::signal.  It can
-do so by declaring itself a [ProxyProducerPortConcept] for the boost::signal.
-
-[heading Port Operations]
-
-To establish a flow of data in a dataflow program, we typically /connect/
-producers and consumers using some type of /connection/. In C++, this is usually
-done through a pointer-like mechanism.  For example, a boost::signal can be used
-by a producer to dissiminate data to multiple consumers which have been
-connected to the signal. Or, a consumer class might have a pointer to a variable
-which it collects data from.
-
-Operations between two ports such as /connect/, /connect_only/, /disconnect/,
-and /extract/ are captured by the [BinaryOperableConcept] concept.  Operations
-on a single port such as /disconnect_all/ are covered by the [UnaryOperableConcept]
-concept.
-
-[/
-[heading Push and pull]
-
-Components can be further categorized according to where the connection lies,
-and what it points to.  If the producer contains the connection(s) which point
-to the consumer(s) (say, a `boost::signal<void (int)>`), the producer is called a
-/push producer/.  If the consumer contains the connection(s) which point to the
-producer(s), the consumer is called a /pull consumer/.  A connection
-between a push producer and a (non-pull) consumer is a /push connection/,
-and a connection between a pull consumer and a (non-push) producer is a
-/pull connection/.
-
-Sometimes things get a little fuzzy - for example, a function
-call can be used to transmit data through the arguments from the caller to the
-callee.  However, the callee can transmit data back to the caller by returning
-it.  Hence, an object which contains a boost::signal could be both a push
-producer (which sends data through the signal argument) and a pull consumer
-(which receives data through the signal return type).  If both directions
-are being used to transmit data, a connection like this is called a /push and
-pull connection/.
-
-It is also possible that the producer points to the consumer and vice versa.
-In this case, the connection is called a /bidirectional connection/.]
-
-[heading Invocation]
-
-[/Another important thing to note is that there is a separation between providing
-the data to a component, and invoking the component.  In some cases, the two
-happen simultaneously (when the data is passed and returned via a function
-call), while in others invoking the computational element can happen
-separately from providing the data (at least from a modeling perspective).
-An example of the latter is a consumer which uses data stored in
-a particular location. We can place the data in that location much before
-invoking the consumer.]
-
-We will call /invoking/ a component (producer or consumer) the action of
-causing it to consume data from connected producers, and producing data
-for connected consumers.
-
-Invocation is captured more formally by the [InvocableConcept] concept.
-
-
-
-[section Mechanism]
-
-[note The Mechanism concept currently has no requirements.]
-
-A Mechanism type is used to specify the mechanism when specializing or invoking
-Dataflow templates.  Each mechanism therefore has a corresponding
-type tag.
-
-[heading Examples]
-
-The following code declares the [VTK] mechanism tag - it is a part of
-the [vtk_example example showing how to provide a VTK support layer].
-
-[vtk_mechanism]
-
-[endsect][/mechanism]
-
-[include port_concepts.qbk]
-
-[section:binaryoperable BinaryOperable (Connectable, OnlyConnectable, Disconnectable, Extractable) ]
-
-A [ProducerPortConcept] `P` and [ConsumerPortConcept] `C` are /BinaryOperable/
-for a binary operation `O`, and mechanism `M`, if the implementation of
-the binary operation `O` has been specialized for `M`, `P`, and `C`.
-
-In this case,
-
-* If `O` is operations::connect, `P` and `C` are [ConnectableConcept]
-* If `O` is operations::connect_only, `P` and `C` are [OnlyConnectableConcept]
-* If `O` is operations::disconnect, `P` and `C` are [DisconnectableConcept]
-* If `O` is operations::extract, `P` and `C` are [ExtractableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [ProducerPortConcept] type.]]
-    [[C_C] [A [ConsumerPortConcept] [ConnectableConcept] with `P`]]
-    [[C_O] [A [ConsumerPortConcept] [OnlyConnectableConcept] with `P`]]
-    [[C_D] [A [ConsumerPortConcept] [DisconnectableConcept] with `P`]]
-    [[C_E] [A [ConsumerPortConcept] [ExtractableConcept] with `P`]]
-    [[p] [An object of type P.]]
-    [[c_c] [An object of type C_C.]]
-    [[c_o] [An object of type C_O.]]
-    [[c_d] [An object of type C_D.]]
-    [[c_e] [An object of type C_E.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Connect]
-        [`binary_operation<operations::connect, M>(p,c_c)`]
-        [void]
-        [
-            Creates a lasting connection between the `p` and `c`.
-        ]
-    ]
-    [
-        [OnlyConnect]
-        [`binary_operation<operations::connect_only, M>(p,c_o)`]
-        [void]
-        [
-            Discards any lasting connections stored by `p` or `c`,
-            and creates a lasting connection between `p` and `c`.
-            Note that `p` or `c` could still be connected to other ports,
-            as long as these connections are not stored in `p` or `c`.
-        ]
-    ]
-    [
-        [Disconnect]
-        [`binary_operation<operations::disconnect, M>(p,c_d)`]
-        [void]
-        [
-            Discards any existing connection between `p` and `c`.
-        ]
-    ]
-    [
-        [Extract]
-        [`binary_operation<operations::extract, M>(p,c_e)`]
-        [void]
-        [
-            Perfoms a one time transfer of data from `p` to `c`.
-        ]
-    ]
-]
-
-[endsect][/binaryoperable]
-
-[section:unaryoperable UnnaryOperable (AllDisconnectable) ]
-
-A [PortConcept] `P` is /UnnaryOperable/
-for a unary operation `O`, and mechanism `M`, if the implementation of
-the unnary operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::disconnect_all, `P` is [AllDisconnectable]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [PortConcept] type.]]
-    [[p] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Disconnect All]
-        [`unnary_operation<operations::disconnect_all, M>(p)`]
-        [void]
-        [
-            Destroys any connections stored by `p`.  
-        ]
-    ]
-]
-
-[endsect][/unaryoperable]
-
-[section ComponentTraits]
-
-A ['[ComponentTraitsConcept]] specifies the traits of a [ComponentConcept].
-
-[heading Notation]
-[variablelist
-    [[CT] [A ComponentTraits type.]]
-    [[C] [A [ComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types.]
-        [[PortTraitsConcept] of exposed [PortConcept]s.]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/componenttraits]
-
-[section ReflectiveComponentTraits]
-
-A ['[ReflectiveComponentTraitsConcept]] specifies the traits of a [ReflectiveComponentConcept].
-
-[heading Refinement of]
-
-* [ComponentTraitsConcept]
-
-[heading Notation]
-[variablelist
-    [[CT] [A ReflectiveComponentTraits type.]]
-    [[C] [A [ReflectiveComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types]
-        [
-            An enumeration of the [PortTraitsConcept] of the exposed
-            [PortConcept]s.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/reflectivecomponenttraits]
-
-[section Component]
-
-[note The Component concept is not fully fleshed out.  It lacks any
-functionality related to getting access to any [PortConcept] that is
-a part of the component.]
-
-A type `C` is a ['[ComponentConcept]] for a mechanism `M`
-if it specifies a [ComponentTraitsConcept] for that mechanism.
-
-[heading Refinements]
-
-* [ReflectiveComponentConcept]
+The traits of a component are held in a ['[ComponentTraitsConcept]] type.
+There are multiple ways of registering the [ComponentTraitsConcept]
+for a [ComponentConcept] (see examples below).
 
 [heading Notation]
-The following expressions are used in this document:
-
 [variablelist
-    [[C] [A Component type.]]
-    [[M] [A [MechanismConcept] type.]]
+    [[C] [A [ComponentConcept] type.]]
+    [[CT] [The [ComponentTraitsConcept] type of `C`.]]
+    [[I] [An MPL Integral Constant in the range \[0, n of ports exposed by C).]]
+    [[c] [An object of type C.]]
 ]
 
-[heading Requirements]
+[heading Component Requirements]
 [table
     [[Name] [Expression] [Result Type] [Semantics]]
     [
         [Component Traits]
         [`component_traits_of<M, C>::type`]
-        [Any [ComponentTraitsConcept] type]
+        [`CT`]
         [
             The [ComponentTraitsConcept] of the component.
         ]
@@ -370,62 +36,6 @@
             concept.
         ]
     ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-[section ReflectiveComponent]
-
-A [ComponentConcept] `C` for a mechanism `M` is a ['[ReflectiveComponentConcept]] 
-if's [ComponentTraitsConcept] is a [ReflectiveComponentTraitsConcept], and it
-specializes the `get_component_port_impl` implementation to provide access
-to it's ports.
-
-[heading Refinement of]
-
-* [ComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A ReflectiveComponent type.]]
-    [[M] [A [MechanismConcept] type.]]
-    [[I] [An MPL Integral Constant in the range 0, n of ports exposed by C.]]
-    [[c] [An object of type C.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ReflectiveComponentTraitsConcept] type]
-        [
-            The [ReflectiveComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsReflectiveComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the ReflectiveComponent
-            concept.
-        ]
-    ]
     [
         [ GetComponentPort ]
         [`get_component_port<M, I>(c)`]
@@ -436,6 +46,20 @@
     ]
 ]
 
+[heading ComponentTraits Requirements]
+[table
+    [[Name] [Expression] [Result Type] [Semantics]]
+    [
+        [Port Traits]
+        [`CT::ports`]
+        [MPL Sequence of [PortTraitsConcept] types]
+        [
+            An enumeration of the [PortTraitsConcept] of the exposed
+            [PortConcept]s.
+        ]
+    ]
+]
+
 [heading Header]
 
 ```
@@ -447,7 +71,9 @@
 
 [heading Examples]
 
-[endsect][/component]
+... to come ...
+
+[endsect][/componenttraits]
 
 
 [section:componentoperable ComponentOperable (Invocable) ]
@@ -483,5 +109,3 @@
 ]
 
 [endsect][/componentoperable]
-
-[endsect][/concepts]

Copied: sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/concepts.qbk (from r41347, /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk)
==============================================================================
--- /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/concepts.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -26,17 +26,22 @@
 
 [heading Mechanisms]
 
-There are many different environments that offer dataflow-related functionality.
+There are many different ways of transferring data in a dataflow detwork.
 For example, [BoostSignals] offers transfer of data through function calls,
 while [VTK] offers a number of classes which are meant to be connected in
 a pipline (e.g., starting with the data source, manipulating it, and
 finally displaying it on the screen).
 
 [BoostSignals] and [VTK] are examples of different /mechanisms/ - particular
-environments each offering their own, independent way of doing dataflow.
-In the Dataflow library, everything is keyed through a mechanism type
-tag, allowing different mechanisms to be specified independently, and
-allowing a single component to support muliple mechanisms.
+ways of performing data transfer.  A particular dataflow framework and/or its
+Dataflow library support layer might use one or more mechanisms in its
+implementation.
+
+In the Dataflow library, most port related class templates are keyed through
+a [MechanismConcept] type tag.  For example, the [DataflowSignals] layer
+uses two mechanisms for its ports and related operations - one mechanism
+is used for lasting connections between a `signal` and a `function`, while
+another is used for one-time extractions of data.
 
 [heading Ports]
 
@@ -129,14 +134,14 @@
 
 Invocation is captured more formally by the [InvocableConcept] concept.
 
-
+[section Port related]
 
 [section Mechanism]
 
 [note The Mechanism concept currently has no requirements.]
 
 A Mechanism type is used to specify the mechanism when specializing or invoking
-Dataflow templates.  Each mechanism therefore has a corresponding
+port-related Dataflow templates.  Each mechanism therefore has a corresponding
 type tag.
 
 [heading Examples]
@@ -148,340 +153,18 @@
 
 [endsect][/mechanism]
 
-[include port_concepts.qbk]
-
-[section:binaryoperable BinaryOperable (Connectable, OnlyConnectable, Disconnectable, Extractable) ]
-
-A [ProducerPortConcept] `P` and [ConsumerPortConcept] `C` are /BinaryOperable/
-for a binary operation `O`, and mechanism `M`, if the implementation of
-the binary operation `O` has been specialized for `M`, `P`, and `C`.
-
-In this case,
-
-* If `O` is operations::connect, `P` and `C` are [ConnectableConcept]
-* If `O` is operations::connect_only, `P` and `C` are [OnlyConnectableConcept]
-* If `O` is operations::disconnect, `P` and `C` are [DisconnectableConcept]
-* If `O` is operations::extract, `P` and `C` are [ExtractableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [ProducerPortConcept] type.]]
-    [[C_C] [A [ConsumerPortConcept] [ConnectableConcept] with `P`]]
-    [[C_O] [A [ConsumerPortConcept] [OnlyConnectableConcept] with `P`]]
-    [[C_D] [A [ConsumerPortConcept] [DisconnectableConcept] with `P`]]
-    [[C_E] [A [ConsumerPortConcept] [ExtractableConcept] with `P`]]
-    [[p] [An object of type P.]]
-    [[c_c] [An object of type C_C.]]
-    [[c_o] [An object of type C_O.]]
-    [[c_d] [An object of type C_D.]]
-    [[c_e] [An object of type C_E.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Connect]
-        [`binary_operation<operations::connect, M>(p,c_c)`]
-        [void]
-        [
-            Creates a lasting connection between the `p` and `c`.
-        ]
-    ]
-    [
-        [OnlyConnect]
-        [`binary_operation<operations::connect_only, M>(p,c_o)`]
-        [void]
-        [
-            Discards any lasting connections stored by `p` or `c`,
-            and creates a lasting connection between `p` and `c`.
-            Note that `p` or `c` could still be connected to other ports,
-            as long as these connections are not stored in `p` or `c`.
-        ]
-    ]
-    [
-        [Disconnect]
-        [`binary_operation<operations::disconnect, M>(p,c_d)`]
-        [void]
-        [
-            Discards any existing connection between `p` and `c`.
-        ]
-    ]
-    [
-        [Extract]
-        [`binary_operation<operations::extract, M>(p,c_e)`]
-        [void]
-        [
-            Perfoms a one time transfer of data from `p` to `c`.
-        ]
-    ]
-]
-
-[endsect][/binaryoperable]
-
-[section:unaryoperable UnnaryOperable (AllDisconnectable) ]
-
-A [PortConcept] `P` is /UnnaryOperable/
-for a unary operation `O`, and mechanism `M`, if the implementation of
-the unnary operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::disconnect_all, `P` is [AllDisconnectable]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [PortConcept] type.]]
-    [[p] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Disconnect All]
-        [`unnary_operation<operations::disconnect_all, M>(p)`]
-        [void]
-        [
-            Destroys any connections stored by `p`.  
-        ]
-    ]
-]
-
-[endsect][/unaryoperable]
-
-[section ComponentTraits]
-
-A ['[ComponentTraitsConcept]] specifies the traits of a [ComponentConcept].
-
-[heading Notation]
-[variablelist
-    [[CT] [A ComponentTraits type.]]
-    [[C] [A [ComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types.]
-        [[PortTraitsConcept] of exposed [PortConcept]s.]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/componenttraits]
+[include port.qbk]
 
-[section ReflectiveComponentTraits]
-
-A ['[ReflectiveComponentTraitsConcept]] specifies the traits of a [ReflectiveComponentConcept].
-
-[heading Refinement of]
-
-* [ComponentTraitsConcept]
-
-[heading Notation]
-[variablelist
-    [[CT] [A ReflectiveComponentTraits type.]]
-    [[C] [A [ReflectiveComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types]
-        [
-            An enumeration of the [PortTraitsConcept] of the exposed
-            [PortConcept]s.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/reflectivecomponenttraits]
-
-[section Component]
-
-[note The Component concept is not fully fleshed out.  It lacks any
-functionality related to getting access to any [PortConcept] that is
-a part of the component.]
-
-A type `C` is a ['[ComponentConcept]] for a mechanism `M`
-if it specifies a [ComponentTraitsConcept] for that mechanism.
-
-[heading Refinements]
-
-* [ReflectiveComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A Component type.]]
-    [[M] [A [MechanismConcept] type.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ComponentTraitsConcept] type]
-        [
-            The [ComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the Component
-            concept.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-[section ReflectiveComponent]
-
-A [ComponentConcept] `C` for a mechanism `M` is a ['[ReflectiveComponentConcept]] 
-if's [ComponentTraitsConcept] is a [ReflectiveComponentTraitsConcept], and it
-specializes the `get_component_port_impl` implementation to provide access
-to it's ports.
-
-[heading Refinement of]
-
-* [ComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A ReflectiveComponent type.]]
-    [[M] [A [MechanismConcept] type.]]
-    [[I] [An MPL Integral Constant in the range 0, n of ports exposed by C.]]
-    [[c] [An object of type C.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ReflectiveComponentTraitsConcept] type]
-        [
-            The [ReflectiveComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsReflectiveComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the ReflectiveComponent
-            concept.
-        ]
-    ]
-    [
-        [ GetComponentPort ]
-        [`get_component_port<M, I>(c)`]
-        []
-        [
-            Returns the I'th [PortConcept] exposed by `C`
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
+[include binary_operable.qbk]
 
-[endsect][/component]
+[include unary_operable.qbk]
 
+[endsect] [/port related]
 
-[section:componentoperable ComponentOperable (Invocable) ]
+[section Component related]
 
-A [ComponentConcept] `P` is /ComponentOperable/
-for a component operation `O`, and mechanism `M`, if the implementation of
-the component operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::invoke, `P` is [InvocableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A [ComponentConcept] type.]]
-    [[c] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Invoke]
-        [`component_operation<operations::invoke, M>(p)`]
-        [Any type]
-        [
-            Invokes `c` - this typically causes a component to consume its
-            input data and produce its output data as appropriate.  
-        ]
-    ]
-]
+[include component.qbk]
 
-[endsect][/componentoperable]
+[endsect][/component related]
 
 [endsect][/concepts]

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/port.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/port.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/port.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -127,7 +127,7 @@
     [
         [Port Concept]
         [`PT::port_concept`]
-        [`concepts::port`, `concepts::keyed_port`]
+        [`concepts::port`, `concepts::keyed_port`, `concepts::complemented_port`]
         [The most refined producer concept that `P` satisfies.]
     ]
 
@@ -207,7 +207,7 @@
 [endsect][/port]
 
 
-[section ComplementedPort]
+[section:complementedport ComplementedPort, ComplementedPortTraits]
 
 A ComplementedPort `P` is a [PortConcept] s.t. whenever it is
 [BinaryOperableConcept] with another [PortConcept] `P2`, `P2` is
@@ -263,23 +263,21 @@
         [`PT::complement_port_type`]
         [Any [PortConcept] type]
         [
-            The complement port type of the port type `P`.  `P` can only be
-            [BinaryOperableConcept] with the complement port type.
+            The complement port type of the port type `P`.  If `P` is 
+            [BinaryOperableConcept] with another port type `P2`, then
+            `get_port<PT::mechanism, PT::category::complement>(p2)` must
+            return an object of type `PT::complement_port_type` or reference
+            to such.
         ]
     ]
 ]
 
-
-
 [endsect]
 
+[section KeyedPort]
+[endsect][/keyed_port]
 
-[section ProxyPortTraits]
-
-
-[endsect][/proxyporttraits]
-
-[section ProxyPort]
+[section ProxyPort, ProxyPortTraits]
 
 A type `PP` is a ['[ProxyPortConcept]] for a mechanism `M` and port category `PC`
 if it specifies a [ProxyPortTraitsConcept] for that mechanism and port category.
@@ -324,5 +322,3 @@
 
 [endsect][/proxyport]
 
-[section KeyedPort]
-[endsect][/keyed_port]

Copied: sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/unary_operable.qbk (from r41347, /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk)
==============================================================================
--- /sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/component.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/concepts/unary_operable.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -1,225 +1,3 @@
-[section Concepts]
-
-[/To explore generic dataflow in C++, let us begin by examining where the flow of
-data happens in C++.  Rather informally, we can divide things as follows:
-
-* on one hand, there is data (variables, objects, etc...)
-* on the other, there are computational elements (functions, methods, etc...)
-
-Data can then be processed by the computational
-elements by applying the elements to the data in some appropriate way.
-There are several ways of providing data to the computational elements:
-
-* by placing it in a location where the computational element will read it
-* by passing it as a parameter in a call
-* (a combination of the above) by passing the location of the data as a
-parameter in a call
-
-Similarly, there are several ways of getting data out of a computational element:
-
-* the element makes a function call that carries the data as a parameter
-* the element places a value somewhere where it can be read
-* the element returns it as a return value
-
-With the above in mind, let's informally introduce a few concepts related to dataflow
-programming:]
-
-[heading Mechanisms]
-
-There are many different environments that offer dataflow-related functionality.
-For example, [BoostSignals] offers transfer of data through function calls,
-while [VTK] offers a number of classes which are meant to be connected in
-a pipline (e.g., starting with the data source, manipulating it, and
-finally displaying it on the screen).
-
-[BoostSignals] and [VTK] are examples of different /mechanisms/ - particular
-environments each offering their own, independent way of doing dataflow.
-In the Dataflow library, everything is keyed through a mechanism type
-tag, allowing different mechanisms to be specified independently, and
-allowing a single component to support muliple mechanisms.
-
-[heading Ports]
-
-The fundamental point of data production or consumption is called a /port/.
-Two complementary ports that produce / consume the same type of data (using
-the same type of mechanism) can typically be connected/disconnected, or data
-can be extracted from one port to another.
-
-Depending on the data-transport mechanism used, a producer port could be anything
-that produces / provides data:  a POD variable, an object of a class type, or
-a function that returns a value.  Similarly, a consumer port could be anything
-that consumes data - a function that takes an argument, a functor, etc.
-
-Ports are captured more formally by the [PortConcept] concept.
-
-[heading Components]
-
-A /component/ is the fundamental data processing element of a dataflow
-network.  It can have multiple ports, for example a video filter component
-might have one consumer port (consuming video to be processed) and one
-producer port (producing filtered video).
-
-Typically, a component is embedded in a class, and the different [PortConcept]s
-are accessible either through the class directly, or through its member
-functions and variables.
-
-The Dataflow library also offers a [ComponentConcept] concept, which is
-intented to provide compile-time introspection and other operations.
-
-[heading Proxies]
-
-It is often the case that a port delegates its [PortConcept]
-functionality to some other element.  For example, a
-class that is a [DataflowSignals] component might delegate its
-[ProducerPortConcept] functionality to a member boost::signal.  It can
-do so by declaring itself a [ProxyProducerPortConcept] for the boost::signal.
-
-[heading Port Operations]
-
-To establish a flow of data in a dataflow program, we typically /connect/
-producers and consumers using some type of /connection/. In C++, this is usually
-done through a pointer-like mechanism.  For example, a boost::signal can be used
-by a producer to dissiminate data to multiple consumers which have been
-connected to the signal. Or, a consumer class might have a pointer to a variable
-which it collects data from.
-
-Operations between two ports such as /connect/, /connect_only/, /disconnect/,
-and /extract/ are captured by the [BinaryOperableConcept] concept.  Operations
-on a single port such as /disconnect_all/ are covered by the [UnaryOperableConcept]
-concept.
-
-[/
-[heading Push and pull]
-
-Components can be further categorized according to where the connection lies,
-and what it points to.  If the producer contains the connection(s) which point
-to the consumer(s) (say, a `boost::signal<void (int)>`), the producer is called a
-/push producer/.  If the consumer contains the connection(s) which point to the
-producer(s), the consumer is called a /pull consumer/.  A connection
-between a push producer and a (non-pull) consumer is a /push connection/,
-and a connection between a pull consumer and a (non-push) producer is a
-/pull connection/.
-
-Sometimes things get a little fuzzy - for example, a function
-call can be used to transmit data through the arguments from the caller to the
-callee.  However, the callee can transmit data back to the caller by returning
-it.  Hence, an object which contains a boost::signal could be both a push
-producer (which sends data through the signal argument) and a pull consumer
-(which receives data through the signal return type).  If both directions
-are being used to transmit data, a connection like this is called a /push and
-pull connection/.
-
-It is also possible that the producer points to the consumer and vice versa.
-In this case, the connection is called a /bidirectional connection/.]
-
-[heading Invocation]
-
-[/Another important thing to note is that there is a separation between providing
-the data to a component, and invoking the component.  In some cases, the two
-happen simultaneously (when the data is passed and returned via a function
-call), while in others invoking the computational element can happen
-separately from providing the data (at least from a modeling perspective).
-An example of the latter is a consumer which uses data stored in
-a particular location. We can place the data in that location much before
-invoking the consumer.]
-
-We will call /invoking/ a component (producer or consumer) the action of
-causing it to consume data from connected producers, and producing data
-for connected consumers.
-
-Invocation is captured more formally by the [InvocableConcept] concept.
-
-
-
-[section Mechanism]
-
-[note The Mechanism concept currently has no requirements.]
-
-A Mechanism type is used to specify the mechanism when specializing or invoking
-Dataflow templates.  Each mechanism therefore has a corresponding
-type tag.
-
-[heading Examples]
-
-The following code declares the [VTK] mechanism tag - it is a part of
-the [vtk_example example showing how to provide a VTK support layer].
-
-[vtk_mechanism]
-
-[endsect][/mechanism]
-
-[include port_concepts.qbk]
-
-[section:binaryoperable BinaryOperable (Connectable, OnlyConnectable, Disconnectable, Extractable) ]
-
-A [ProducerPortConcept] `P` and [ConsumerPortConcept] `C` are /BinaryOperable/
-for a binary operation `O`, and mechanism `M`, if the implementation of
-the binary operation `O` has been specialized for `M`, `P`, and `C`.
-
-In this case,
-
-* If `O` is operations::connect, `P` and `C` are [ConnectableConcept]
-* If `O` is operations::connect_only, `P` and `C` are [OnlyConnectableConcept]
-* If `O` is operations::disconnect, `P` and `C` are [DisconnectableConcept]
-* If `O` is operations::extract, `P` and `C` are [ExtractableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[P] [A [ProducerPortConcept] type.]]
-    [[C_C] [A [ConsumerPortConcept] [ConnectableConcept] with `P`]]
-    [[C_O] [A [ConsumerPortConcept] [OnlyConnectableConcept] with `P`]]
-    [[C_D] [A [ConsumerPortConcept] [DisconnectableConcept] with `P`]]
-    [[C_E] [A [ConsumerPortConcept] [ExtractableConcept] with `P`]]
-    [[p] [An object of type P.]]
-    [[c_c] [An object of type C_C.]]
-    [[c_o] [An object of type C_O.]]
-    [[c_d] [An object of type C_D.]]
-    [[c_e] [An object of type C_E.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Connect]
-        [`binary_operation<operations::connect, M>(p,c_c)`]
-        [void]
-        [
-            Creates a lasting connection between the `p` and `c`.
-        ]
-    ]
-    [
-        [OnlyConnect]
-        [`binary_operation<operations::connect_only, M>(p,c_o)`]
-        [void]
-        [
-            Discards any lasting connections stored by `p` or `c`,
-            and creates a lasting connection between `p` and `c`.
-            Note that `p` or `c` could still be connected to other ports,
-            as long as these connections are not stored in `p` or `c`.
-        ]
-    ]
-    [
-        [Disconnect]
-        [`binary_operation<operations::disconnect, M>(p,c_d)`]
-        [void]
-        [
-            Discards any existing connection between `p` and `c`.
-        ]
-    ]
-    [
-        [Extract]
-        [`binary_operation<operations::extract, M>(p,c_e)`]
-        [void]
-        [
-            Perfoms a one time transfer of data from `p` to `c`.
-        ]
-    ]
-]
-
-[endsect][/binaryoperable]
 
 [section:unaryoperable UnnaryOperable (AllDisconnectable) ]
 
@@ -253,235 +31,3 @@
 ]
 
 [endsect][/unaryoperable]
-
-[section ComponentTraits]
-
-A ['[ComponentTraitsConcept]] specifies the traits of a [ComponentConcept].
-
-[heading Notation]
-[variablelist
-    [[CT] [A ComponentTraits type.]]
-    [[C] [A [ComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types.]
-        [[PortTraitsConcept] of exposed [PortConcept]s.]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/componenttraits]
-
-[section ReflectiveComponentTraits]
-
-A ['[ReflectiveComponentTraitsConcept]] specifies the traits of a [ReflectiveComponentConcept].
-
-[heading Refinement of]
-
-* [ComponentTraitsConcept]
-
-[heading Notation]
-[variablelist
-    [[CT] [A ReflectiveComponentTraits type.]]
-    [[C] [A [ReflectiveComponentConcept] type of traits `CT`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PC::ports`]
-        [MPL Sequence of [PortTraitsConcept] types]
-        [
-            An enumeration of the [PortTraitsConcept] of the exposed
-            [PortConcept]s.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/reflectivecomponenttraits]
-
-[section Component]
-
-[note The Component concept is not fully fleshed out.  It lacks any
-functionality related to getting access to any [PortConcept] that is
-a part of the component.]
-
-A type `C` is a ['[ComponentConcept]] for a mechanism `M`
-if it specifies a [ComponentTraitsConcept] for that mechanism.
-
-[heading Refinements]
-
-* [ReflectiveComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A Component type.]]
-    [[M] [A [MechanismConcept] type.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ComponentTraitsConcept] type]
-        [
-            The [ComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the Component
-            concept.
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-[section ReflectiveComponent]
-
-A [ComponentConcept] `C` for a mechanism `M` is a ['[ReflectiveComponentConcept]] 
-if's [ComponentTraitsConcept] is a [ReflectiveComponentTraitsConcept], and it
-specializes the `get_component_port_impl` implementation to provide access
-to it's ports.
-
-[heading Refinement of]
-
-* [ComponentConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A ReflectiveComponent type.]]
-    [[M] [A [MechanismConcept] type.]]
-    [[I] [An MPL Integral Constant in the range 0, n of ports exposed by C.]]
-    [[c] [An object of type C.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Component Traits]
-        [`component_traits_of<M, C>::type`]
-        [Any [ReflectiveComponentTraitsConcept] type]
-        [
-            The [ReflectiveComponentTraitsConcept] of the component.
-        ]
-    ]
-    [
-        [IsReflectiveComponent Trait]
-        [`is_component<M, C>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the ReflectiveComponent
-            concept.
-        ]
-    ]
-    [
-        [ GetComponentPort ]
-        [`get_component_port<M, I>(c)`]
-        []
-        [
-            Returns the I'th [PortConcept] exposed by `C`
-        ]
-    ]
-]
-
-[heading Header]
-
-```
-    #include <boost/dataflow/support/component.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/component]
-
-
-[section:componentoperable ComponentOperable (Invocable) ]
-
-A [ComponentConcept] `P` is /ComponentOperable/
-for a component operation `O`, and mechanism `M`, if the implementation of
-the component operation `O` has been specialized for `M` and `P`
-
-In this case,
-
-* If `O` is operations::invoke, `P` is [InvocableConcept]
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[C] [A [ComponentConcept] type.]]
-    [[c] [An object of type P.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Invoke]
-        [`component_operation<operations::invoke, M>(p)`]
-        [Any type]
-        [
-            Invokes `c` - this typically causes a component to consume its
-            input data and produce its output data as appropriate.  
-        ]
-    ]
-]
-
-[endsect][/componentoperable]
-
-[endsect][/concepts]

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/dataflow.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -13,32 +13,33 @@
 ]
 
 [template concepts[] [link dataflow.concepts concepts]]
-[template MechanismConcept[] [link dataflow.concepts.mechanism [^Mechanism]]]
-[template PortCategoryConcept[] [link dataflow.concepts.portcategory [^PortCategory]]]
-[template PortTraitsConcept[] [link dataflow.concepts.porttraits [^PortTraits]]]
-[template PortConcept[] [link dataflow.concepts.port [^Port]]]
-[template ProducerPortConcept[] [link dataflow.concepts.port [^ProducerPort]]]
-[template ConsumerPortConcept[] [link dataflow.concepts.port [^ConsumerPort]]]
-[template KeyedPortConcept[] [link dataflow.concepts.keyedport [^KeyedPort]]]
-[template ProxyPortTraitsConcept[] [link dataflow.concepts.proxyporttraits [^ProxyPortTraits]]]
-[template ProxyPortConcept[] [link dataflow.concepts.proxyport [^ProxyPort]]]
-
-[template ComponentTraitsConcept[] [link dataflow.concepts.componenttraits [^ComponentTraits]]]
-[template ComponentConcept[] [link dataflow.concepts.component [^Component]]]
-[template ReflectiveComponentTraitsConcept[] [link dataflow.concepts.reflectivecomponenttraits [^ReflectiveComponentTraits]]]
-[template ReflectiveComponentConcept[] [link dataflow.concepts.reflectivecomponent [^ReflectiveComponent]]]
-
-[template BinaryOperableConcept[] [link dataflow.concepts.binaryoperable [^BinaryOperable]]]
-[template ConnectableConcept[] [link dataflow.concepts.binaryoperable [^Connectable]]]
-[template OnlyConnectableConcept[] [link dataflow.concepts.binaryoperable [^OnlyConnectable]]]
-[template DisconnectableConcept[] [link dataflow.concepts.binaryoperable [^Disconnectable]]]
-[template ExtractableConcept[] [link dataflow.concepts.binaryoperable [^Extractable]]]
+[template MechanismConcept[] [link dataflow.concepts.port_related.mechanism [^Mechanism]]]
+[template PortCategoryConcept[] [link dataflow.concepts.port_related.portcategory [^PortCategory]]]
+[template PortTraitsConcept[] [link dataflow.concepts.port_related.port [^PortTraits]]]
+[template PortConcept[] [link dataflow.concepts.port_related.port [^Port]]]
+[template ProducerPortConcept[] [link dataflow.concepts.port_related.port [^ProducerPort]]]
+[template ConsumerPortConcept[] [link dataflow.concepts.port_related.port [^ConsumerPort]]]
+[template ComplementedPortConcept[] [link dataflow.concepts.port_related.complementedport [^ComplementedPort]]]
+[template ComplementedPortTraitsConcept[] [link dataflow.concepts.port_related.complementedport [^ComplementedPortTraits]]]
+[template KeyedPortConcept[] [link dataflow.concepts.port_related.keyedport [^KeyedPort]]]
+
+[template ProxyPortTraitsConcept[] [link dataflow.concepts.port_related.proxyporttraits [^ProxyPortTraits]]]
+[template ProxyPortConcept[] [link dataflow.concepts.port_related.proxyport [^ProxyPort]]]
+
+[template BinaryOperableConcept[] [link dataflow.concepts.port_related.binaryoperable [^BinaryOperable]]]
+[template ConnectableConcept[] [link dataflow.concepts.port_related.binaryoperable [^Connectable]]]
+[template OnlyConnectableConcept[] [link dataflow.concepts.port_related.binaryoperable [^OnlyConnectable]]]
+[template DisconnectableConcept[] [link dataflow.concepts.port_related.binaryoperable [^Disconnectable]]]
+[template ExtractableConcept[] [link dataflow.concepts.port_related.binaryoperable [^Extractable]]]
 
-[template UnaryOperableConcept[] [link dataflow.concepts.unaryoperable [^UnaryOperable]]]
-[template AllDisconnectableConcept[] [link dataflow.concepts.unaryoperable [^AllDisconnectable]]]
+[template UnaryOperableConcept[] [link dataflow.concepts.port_related.unaryoperable [^UnaryOperable]]]
+[template AllDisconnectableConcept[] [link dataflow.concepts.port_related.unaryoperable [^AllDisconnectable]]]
 
-[template ComponentOperableConcept[] [link dataflow.concepts.componentoperable [^ComponentOperable]]]
-[template InvocableConcept[] [link dataflow.concepts.componentoperable [^Invocable]]]
+[template ComponentTraitsConcept[] [link dataflow.concepts.component_related.componenttraits [^ComponentTraits]]]
+[template ComponentConcept[] [link dataflow.concepts.component_related.component [^Component]]]
+
+[template ComponentOperableConcept[] [link dataflow.concepts.component_related.componentoperable [^ComponentOperable]]]
+[template InvocableConcept[] [link dataflow.concepts.component_related.componentoperable [^Invocable]]]
 
 [template SignalPortTraitsConcept[] [link dataflow.signals.concepts.signalporttraits [^SignalPortTraits]]]
 [template SignalProducerConcept[] [link dataflow.signals.concepts.signalproducer [^SignalProducer]]]
@@ -88,8 +89,13 @@
 [template BoostThread[] [@http://www.boost.org/doc/html/thread.html Boost.Thread]]
 [template BoostPhoenix2[] [@http://spirit.sourceforge.net/ Boost.Phoenix2]]
 [template BoostPhoenix[] [@http://spirit.sourceforge.net/ Boost.Phoenix]]
+[template BoostGraph[] [@http://www.boost.org/libs/graph/doc/index.html Boost Graph Library]]
 [template BoostAsio[] [@http://asio.sourceforge.net/boost_asio_0_3_8/libs/asio/doc/html/index.html Boost.Asio]]
 [template BoostSerialization[] [@http://www.boost.org/libs/serialization/doc/index.html Boost.Serialization]]
+[template BoostGIL[] [@http://opensource.adobe.com/gil/ Boost.GIL]]
+
+[template GNURadio[] [@http://www.gnu.org/software/gnuradio/ GNU Radio]]
+
 [template WikiDataflow[] [@http://en.wikipedia.org/wiki/Dataflow_programming dataflow]]
 [template VTK[] [@http://www.vtk.org/ VTK]]
 [template vtkAlgorithm[] [@http://www.vtk.org/doc/nightly/html/classvtkAlgorithm.html ['vtkAlgorithm]]]
@@ -134,9 +140,9 @@
 
 [import ../example/blueprint/blueprint_example.cpp]
 
-[include introduction.qbk]
+[include introduction/introduction.qbk]
 
-[include concepts.qbk]
+[include concepts/concepts.qbk]
 
 [/[include components.qbk]]
 

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/future.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/future.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/future.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -4,7 +4,7 @@
 
 The [DataflowBlueprint] layer now offers some limited dataflow network modeling
 via a BGL graph, and some basic runtime reflections for classes that model
-the [ReflectiveComponentConcept] concept.
+the [ComponentConcept] concept.
 
 The following features are planned for the future:
 
@@ -14,6 +14,13 @@
   
 * *Component banks* - Banks of components which can be accessed at runtime.
 
+* *Dataflow support layer* - [DataflowBlueprint] ports, components and networks
+  should model the generic dataflow [concepts].  This will allow the use of
+  the common syntax, as well as the creation of blueprints of blueprints :-)
+
+* *Python bindings* - runtime configuration and operation of networks using
+  Python scripts.
+
 * *Documentation* - non-existant at this point...
 
 [endsect]
@@ -37,15 +44,16 @@
 
 [section:layers Support for more layers]
 
-Several boost libraries are prime candidates for dataflow support, and the
+Several existing libraries and dataflow frameworks are prime candidates for
+Dataflow library support, and the
 usefulness of the dataflow library would greatly increase either by adding
 support layers for these libraries, or providing examples of how to use these
 libraries with existing layers.
 
 Some of these libraries are:
 
-* Boost.Iostreams
-* Boost.GIL
+* [BoostIostreams]
+* [GNURadio] (thanks to Phil Endecott for the reference)
 
 [endsect]
 
@@ -63,7 +71,7 @@
 - the pins at each processing component could be in, out, or in/out, and links
 created by connecting two pins could be categorized as push, pull, push/pull,
 and would also have support for update tracking and trigger modes.  The
-framework would provide support for the data transport components and link/pin
+framework would provide support for the data transport objects and link/pin
 management, and would also be in charge of invoking the components (which
 could be done in an optimized way, depending on what parts of the network
 need to be updated).
@@ -85,14 +93,10 @@
 library with the new generic-oriented [DataflowPhoenix], it is now
 a little clearer how the pin-based approach that Tobias proposed could
 be adapted into the generic Dataflow framework.
-Instead of a direct
-connection from a data-producing component to a data-consuming component,
-as is now typically done in both of the Dataflow modules,
-there would be a connection from a data-producing component's pin
-to a data transport component, and again a connection from the data transport
-component to to the pin of the data-consuming component.
-The processing components would be [InvocableConcept], while each data transport
-component would be both a [ProducerPortConcept] and a [ConsumerPortConcept].
+Here, a connection from a data-producing component to a data-consuming
+component would lead to them both being connected to the same data-transport
+object, which would be managed by the library.  The components
+could be invoked through the [InvocableConcept] by the library when needed.
 
 There are, of course, a lot of other issues to solve, and a lot of ways in
 which the Dataflow generic support layer might need to grow to accomodate

Deleted: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
+++ (empty file)
@@ -1,431 +0,0 @@
-[section:introduction Introduction]
-
-[warning Dataflow is not a part of the Boost libraries.  It was developed
-as a part of the Google Summer of Code program.  The original proposal (for
-the Signal Network library, which became the Dataflow library)
-as well as some GSoC status updates can be found on the
-[@http://svn.boost.org/trac/boost/wiki/soc/2007/SignalNetwork GSoC page].]
-
-Dataflow is a generic library for [WikiDataflow] programming using various data
-transport mechanisms.  It also has layers of support for
-two data transport mechanisms - one is based on
-[BoostSignals], and the other (experimental and currently broken) is based
-connections made through
-simple object pointers, with support for using [BoostPhoenix2]
-actors for data processing.
-
-The two data transport mechanisms are implemented in the [DataflowSignals]
-and [DataflowPhoenix] layers.  The idea behind providing a generic dataflow
-library is that other data transport mechanisms can be easily adapted for
-use with the library, and benefit from layers built on top of it
-(such as the recently started [DataflowBlueprint] layer).
-
-* If you would like some more information about why one would want to connect
-  objects into a dataflow network, read about
-  [link dataflow.introduction.dataflow Dataflow programming in C++].
-* If you'd like to try out the library
-    * keep in mind that the interface is subject to change
-    * Read [how_to_use how to use this library and the documentation].
-
-[section:dataflow Dataflow programming in C++ - motivation and advantages]
-
-The [WikiDataflow] programming paradigm is based on interconnected
-/components/ which process passing /data/.  Basically, data is treated
-as something that originates from a source, flows through a number of
-processing components that manipulate it (e.g., by changing it,
-duplicating, etc.), and arrives at some final destination.  As such,
-the dataflow paradigm is most suitable when developing applications that
-are themselves focused on the "flow" of data.
-
-Perhaps the most readily available examples of a
-dataflow-oriented applications come from the realm of real-time
-[@http://en.wikipedia.org/wiki/Signal_processing signal processing],
-e.g. a video signal processor which perhaps starts with a video input,
-modifies it through a number of processing components (video filters),
-and finally outputs it to a video display.  Another example is event
-processing.
-
-[heading A motivating example]
-
-Let's take a simple real-time camera-input-displayed-on-the-screen application.
-Suppose there are three parts to the application - getting each image frame
-from the camera, processing the image in some way,
-and displaying it on the screen. To see how we might arrive at
-a dataflow-oriented implementation of this application,
-let's first begin with an imperative approach.  Such an implementation might
-be structured as follows:
-
-[$dataflow1.png]
-
-Basically, the main program loop is a series of instructions which does
-this particular job.  To take this a step further in the dataflow direction,
-we note that video input libraries often provide callback
-functionality which will deliver a video stream as a sequence of
-image frames given at the appropriate frame rate.
-With this in mind, we do the following:
-
-# implement a function which takes an image as input.
- # the function first invokes the image processing library function that
-   modifies the image as appropriate
- # the function then invokes the GUI library function that displays the image
-# register the function as a callback with the camera library
-# the main program loop can relax and have some coffee.
-
-The situation now looks something like this:
-
-[$dataflow2.png]
-
-So now, the image library is acting as a data/signal producer - it
-generates images at a certain frame rate.  And the function we
-implemented seems to be a signal consumer which can take an image,
-process it, and display it on the screen.  
-
-This now employs the basic elements of the dataflow paradigm, but we could
-take it even further.  Instead of just having two components, one image
-signal generator and one signal consumer, how about this:
-
-# implement a component which accepts an input image signal,
-  modifies the image as appropriate, and then outputs
-  a signal with the modified image
-# implement a component which receives an imput image signal and displays
-  it on the screen
-# connect the camera library input stream to the first component
-# connect the first component to the second component
-# the main program loop can relax and have some tea, or even take a nap.
-
-The big picture now looks like the following:
-
-[$dataflow3.png]
-
-To give you a sense of how you would do something like this using the Dataflow
-library, we will present a slightly simplified example using [DataflowSignals].
-Instead of processing images, we will just process numbers - but the dataflow
-parts of the code are pretty much the same.
-
-We will first define a few components to use for our network:
-
-[simple_example_components]
-
-And then connect them in a dataflow network:
-
-[simple_example]
-
-A sample run produces:
-
-[pre
-
-0.213436
--0.49558
-1.57538
--1.0592
-1.83927
-1.88577
-0.604675
-...
-
-]
-
-...not quite image processing, but you get the (dataflow) point :-)
-
-[heading Advantages]
-
-There are already many programming paradigms supported by C++ (either directly or through
-additional libraries), so let's examine what the advantages of the the dataflow paradigm might be.
-
-First of all, [*dataflow programming is not exclusive of other paradigms], so adopting the dataflow paradigm
-does not hinder the use of other techniques.  In fact, in C++ it can't - since the components
-themselves need to be implemented somehow, and we can't recursively define them
-forever as finer and finer dataflow diagrams, the dataflow paradigm relies on other
-programming techniques to do the underlying work.  Also, dataflow does not need
-be used for the entire application implementation.  You can always use it
-for only those parts of the application it is appropriate for, and 
-"extend your fingers" from other parts of the program in order
-to insert data into the dataflow, catch it on the other end, probe and adjust the components, etc.
-You can think of it as working with electronic components and changing the connections, turning knobs,
-flipping switches, or hanging over a circuit board and tinkering with it using, say, a multimeter and a
-5V lead (just do it with care).
-
-Second, [*dataflow promotes some good programming practices].  When developing processing components,
-we have only the incoming data to deal with - with no requirements on where it is coming from.  Hence,
-the developed components tend to be quite versatile and reusable.  In the above example, the image
-processing component can be used with any image data generator - there is nothing inside the component
-that says "get the image from the camera", or "get the image from this type of data source (where the
-type is either a base class or a concept)".  It just does it's thing, no matter where the data is coming
-from.
-
-Third, when used in the right context, [*dataflow programming makes development and maintenance
-very intuitive].  In the image processing example, say you don't want to process the image any more. You can
-just connect the camera signal directly to the screen display and cut out
-the image processing component.  Someone gives you a new video signal generator component you'd like to use as input
-instead of the camera?  Just plug it in. Literally.
-
-Fourth, [*dataflow-oriented programs can be divided between threads, processors, or computers more easily],
-because the data dependencies are much more visible.  In the image processing example, say you have
-the display on a different computer. You can just pass the connection to it through a network socket.
-With the data flow clearly specified, it is much easier to distribute the work either manually or
-even automatically (although the Dataflow library at the moment offers no such automatic functionality).
-
-Finally, [*we are not to far from the advantages of a [@http://en.wikipedia.org/wiki/Visual_programming_language
-visual programming language]], since the components and the connections have a natural graphical representation.
-With a visaul development environment, programming becomes as easy as connecting components with connections
-(again, the Dataflow library provides no visual programming functionality).
-
-[heading Go with the flow?]
-
-If you are interested in exploring the dataflow concept further using
-the Dataflow library, see
-
-* [how_to_use How to use this library and the documentation].
-
-[endsect][/dataflow]
-
-[section:how_to_use How to use this library and the documentation]
-
-The Dataflow library currently has two useful parts:
-
-* A layer providing generic dataflow support, adaptable to various dataflow
-  mechanisms.
-* The [DataflowSignals] layer, with a number of implemented components that
-  facilitate implementation of dataflow networks using [BoostSignals] as
-  a data transport mechanism.
-
-There is also a (currently very experimental) [DataflowPhoenix] layer,
-which uses object pointers with support for
-[BoostPhoenix] actors specifying how the data is processed.
-
-[heading Generic dataflow layer]
-
-There are generic properties of dataflow programs which do not depend on the
-data transport mechanism,
-and can be exploited to develop mechanism-independent dataflow code.
-The generic dataflow layer captures some of these properties, and
-has been sucessfully adapted to three
-different data transport mechanisms ([BoostSignals], pointers in conjunction
-with [BoostPhoenix2], and [VTK] pipelines).
-
-Currently, the most useful functionality gained by developing a Dataflow
-support layer is the ability to connect components in a clean, readable
-manner. As more generic code is developed on top of
-the generic dataflow layer (such as the recently started [DataflowBlueprint]),
-providing a Dataflow support layer for your
-favorite data transport mechanism will be more beneficial.
-
-See the [link dataflow.future future directions] of the Dataflow library
-for an idea of what might become available in the future for data transport
-mechanisms with Dataflow library support.
-
-* If you would like to implement Dataflow support for the data transport
-mechanism you are working with,  see the
-[link dataflow.introduction.examples.new_layer example] showing
-how the [VTK] support layer was developed.
-* If you are interested in developing generic code on top of the dataflow
-layer, see the [concepts] documentation.
-
-[heading Dataflow.Signals layer]
-
-This part of the Dataflow library provides components
-and connection-making capabilty which facilitates large-scale use of
-Boost.Signals as a mechanism to transfer data between processing components.
-
-For examples of how the [DataflowSignals] layer can be used, see:
-
-* The example on developing a 
-  [link dataflow.introduction.examples.distributed distributed dataflow application].
-* The [DataflowSignals] documentation.
-
-[heading Dataflow.Blueprint layer]
-
-[DataflowBlueprint] provides run-time reflection and modeling of dataflow
-networks in a BGL graph for any mechanism with implemented Dataflow support.
-
-The development of this layer has only begun.  To find out more about it, see:
-
-* The example on [link dataflow.introduction.examples.blueprint run-time
-  reflection and connectivity modeling].
-
-
-[/[heading When to use]
-
-While the [link dataflow.introduction.dataflow dataflow] section hopefully
-convinced you that there are circumstances in which a dataflow approach is 
-useful, please keep in mind that there are many circumstances in which this
-is not the case.
-
-First, a dataflow approach really only makes sense when the underlying task is
-really about the flow of data through the components that process it.
-If you can't sketch a concise data flow diagram which truly represents
-the application, the dataflow approach might not be the best option.
-For example, if you are implementing a complicated algorithm which is really
-about the sequence of instructions that need to be executed on the data
-(rather than the data going through well-defined and self-contained
-processing components), you probably should't use the Dataflow library.
-If you are working on an audio or video processing application,
-maybe you should.
-
-Second, the data transport mechanism you choose should reflect the needs of
-the applications closely.  Most of the functionality that the library supports
-at this moment is regarding run-time configurable connections.  If you don't
-need that functionality, you might be wasting resources ([DataflowPhoenix]
-offers some functionality related to compile-time connectability in its
-iterator_relative connections, but that is yet to trickle out into the library
-as a whole).
-
-When using signals as the data transport mechanism, remember that every signal
-sent results in a function call, and if the processing
-components are so minute that the cost of the function
-calls overtakes the cost of the processing,
-using [DataflowSignals] will cause a significant performance hit.  A similar
-situation occurs with [DataflowPhoenix], where each consumer must be invoked.
-
-To sum up, consider using the Dataflow library when:
-
-* The application can be modeled well through the flow of data; and
-* The cost of the processing shadows the cost of the function calls, and any
-  unnecessary overhead caused by any connections that need to be stored.
-]
-
-
-[/[heading Dataflow library organization]
-
-The design of the Dataflow library looks like this:
-
-[xinclude dataflow_table.xml]
-
-The layers are a bottom-up hierarchy, with dependencies
-only on layers underneath.
-The /support/ layer provides the necessary generic traits and functions
-required for generic code to work with mechanism-specific
-components.  Each type of mechanism or component must specialize the elements
-of the support layer to work with the mechanism\/component.
-
-Directly based on the support layer, we have functions like /connect/ and
-/invoke/, which can be used to manipulate generic and mechanism-specific
-components that the library supports.  /Operators/ are based on /connect/.
-
-
-The library also offers a few generic components, which can be used
-to group other components together: [producer_group], [consumer_group],
-and [consumer_map].
-
-The rest of the library is in the mechanism-specific modules [DataflowSignals]
-and [DataflowPhoenix], each of which provide their own support layer, on
-top of which their components are implemented.
-
-As long as the support layer is implemented
-for the mechanism/component, the component should
-work seamlesly with the rest of the dataflow library.
-Essentially, the support layer is a very minimal layer implementing a generic
-and extensible intrusive directed graph framework.
-
-[heading Namespace use]
-
-Since the Dataflow library provides both a generic layer, as well as
-mechanism-specific implementations, its elements are scattered over multiple
-namespaces.
-
-The fundamental user-oriented generic elements, such as `is_producer`,
-`producer_category_of` etc., are located in the `boost::dataflow` namespace.
-Function objects which must be specialized for different data transport
-mechanisms, such as `connect_impl`, are in the `boost::dataflow::extension`
-namespace.  The connection operators are in `boost::dataflow::operators`.
-
-On the other hand, individual data transport mechanism implementations
-are located in the namespace of the data transport mechanism.  For example,
-all of the [DataflowSignals] components are in the `boost::signals` namespace,
-and all of the [DataflowPhoenix] components are in the `boost::phoenix`
-namespace.  Furthermore, free functions such as `connect` and `invoke` are
-imported into the mechanism's namespace, so that they can be used via ADL.
-
-All of the examples shown in this documentation are assuming the use of
-
-    using namespace boost;
-
-[note Since there are multiple namespaces used, the documentation will
-explicitly state the namespace of documented elements wherever it is
-convenient.]
-]
-
-[endsect][/how_to_use]
-
-[section Examples]
-
-[include introduction/distributed_example.qbk]
-[include introduction/gil_example.qbk]
-[include introduction/blueprint_example.qbk]
-[include introduction/vtk_example.qbk]
-
-[endsect][/examples]
-
-[section:download Downloading, building and linking]
-
-[heading Downloading]
-
-I am currently preparing this library for submission for a Boost review. The
-latest version is located in the
-[@http://svn.boost.org/trac/boost/browser/sandbox/SOC/2007/signals Boost sandbox].
-
-The Dataflow library uses the trunk version of Boost - it might not work
-perfectly with release versions of boost.
-
-Version 0.8.1 (under construction)
-
-* started the [DataflowBlueprint] layer (simple runtime reflection and network modeling).
-* expanding the [ComponentConcept] concept (compile-time reflection of ports).
-* VTK example Jamfile now works work with Windows (not just Darwin+X11 VTK).
-* provided an example using Boost.GIL.
-
-Version 0.8.0 -
- \[[@http://www.boost-consulting.com/vault/index.php?direction=&order=&directory=Dataflow& available in the Boost vault]\]
-
-* post-GSoC version
-* generic dataflow support layer with tests and examples
-* Dataflow.Signals layer (fusion-based implementation) with tests and examples
-* VTK example
-* quickbook docs
-
-[/Proposal for Boost / Google SoC version  \[[@signal_network.zip download]\]
-
-* finished the signals::socket_sender and signals::socket_receiver components
-
-Draft proposal for Boost / Google SoC version
-
-* changed the file and namespace structure
-* implemented a file-iteration based mechanism for arity-dependent classes
-* changed the operators used
-* signal_link is now signals::filter and does not need to know it's descendant's type
-* implemented signals::junction, signals::selector, signals::storage, signals::timed_generator,
-  signals::mutex, signals::chain, signals::function classes
-
-Original request for interest version available as attachment to
-[@http://lists.boost.org/Archives/boost/2007/02/116869.php]
-]
-
-[heading Building]
-
-The library comes with Boost.Build Jamfiles for all examples, tests, and docs.
-As long as your BOOST_ROOT environment variable is set, you should be able
-to build each one of those by going to the appropriate directory and
-running bjam.
-
-[warning The Jamfile for the VTK examples currently only works for Darwin
-and for VTK built for X]
-
-The library itself is header only, and requires no linking.  However, parts
-of it depend on boost libraries which do need to be built and linked (see
-the linking information below).
-
-[heading Linking]
-
-The generic Dataflow support layer is header-only, and relies only on other
-Boost header-only libraries (MPL, enable_if, and small parts of fusion).
-
-The [DataflowSignals] layer is dependent on the [BoostSignals] library,
-which must be built and linked.  A few of the components ([socket_sender]
-and [socket_receiver]) are also dependent on [BoostAsio], which depends on
-the System library which must also be built and linked.  A few other components
-([mutex] and [condition]) are dependent on [BoostThread], which has to be
-linked as well.
-
-[endsect][/download]
-
-[endsect][/introduction]

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/blueprint_example.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/blueprint_example.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/blueprint_example.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -9,21 +9,32 @@
 [pre
 Printing runtime info about all of the components:
 
-	source has 2 ports. 
-		port 0 is a producer
-		port 1 is a consumer
-
-	sink has 2 ports. 
-		port 0 is a producer
-		port 1 is a consumer
-
-	source_float has 2 ports. 
-		port 0 is a producer
-		port 1 is a consumer
-
-	sink_float has 2 ports. 
-		port 0 is a producer
-		port 1 is a consumer
+	source has 4 ports. 
+		port 0 is a signals connection producer
+		port 1 is a signals connection consumer
+		port 2 is a signals extraction producer
+		port 3 is a signals extraction consumer
+
+	sink has 4 ports. 
+		port 0 is a signals connection producer
+		port 1 is a signals connection consumer
+		port 2 is a signals extraction producer
+		port 3 is a signals extraction consumer
+
+	source_float has 4 ports. 
+		port 0 is a signals connection producer
+		port 1 is a signals connection consumer
+		port 2 is a signals extraction producer
+		port 3 is a signals extraction consumer
+
+	sink_float has 4 ports. 
+		port 0 is a signals connection producer
+		port 1 is a signals connection consumer
+		port 2 is a signals extraction producer
+		port 3 is a signals extraction consumer
+
+
+Printing some runtime port connectability info:
 
 source port 0 is connectable to sink port 1
 source port 1 is not connectable to sink port 0
@@ -32,7 +43,7 @@
 
 Making blueprint connections: source to sink, source_float to sink_float...
 
-Using BGL to analyze the network... There are 2 independent parts of the network.
+Using BGL to analyze the network... BGL says there are 2 independent parts of the network!
 
 Making a copy of the blueprint.
 
@@ -69,9 +80,6 @@
                 value at sink:100
                 value at source_float:100.1
                 value at sink_float:100.1
-
-
-blueprint_example release has exited with status 0.
 ]
 
 The source is:

Modified: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gil_example.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gil_example.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/gil_example.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -1,8 +1,8 @@
-[section:gil An image processing network using Dataflow.Signals and Boost.GIL]
+[section:gil An image processing network using Dataflow.Signals and [BoostGIL]]
 
 The [link dataflow.introduction.motivation motivation] section introduced a
 hypothetical video processing example.  Here, we will present an actual
-image processing example using Boost.GIL (as much as we can using only
+image processing example using [BoostGIL] (as much as we can using only
 Boost libraries).
 
 Our final network will look like this:
@@ -67,136 +67,137 @@
 
 [pre
 
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
+Use keys ',' and '.' to control the image intensity, 
+and '0' and '1' to switch the display between the unfiltered
+and filtered image. 'q' will exit.
+
+Since we are using cin for the input, REMEMBER TO PRESS ENTER
+after each command.
+
+..........
+..........
+..........
+..........
+..........
+..........
+..........
+..........
+..........
+..........
 
 . <-- input (increase grayscale value)
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
-;;;;;;;;;;
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
 
 . <-- input (increase grayscale value)
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-
 . <-- input (increase grayscale value)
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
+. <-- input (increase grayscale value)
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+xxxxxxxxxx
+
+1 <-- input (switch multiplexer to output of noise adder)
+x+++++xx+x
++++++x+xx+
+xxx+x+x+xx
++x+x++xx++
+xx+++xx+++
+x+x++x++xx
+xx+++++xx+
+++++x+x+++
+xxxxx+xx+x
+xxx++++++x
 
 . <-- input (increase grayscale value)
-##########
-##########
-##########
-##########
-##########
-##########
-##########
-##########
-##########
-##########
+XXxxXXXXxx
+XXXxXxxxXX
+xxxxXxxxXx
+xXxXXxXXXX
+XXxXXxXxXX
+xXxxxXxxxx
+xXxXXXXxXX
+XXxXXXxXxX
+XxXxXXxxxX
+xXxxXxxXXx
 
 , <-- input (decrease grayscale value)
+++++x++x+x
+xxx++++x++
+++++++++++
+x+xxxxxxxx
++x+x+xx+++
+x+x+x+xxxx
+++xx++++x+
++x+x++++++
++xxx+++xxx
+x+xx+x+++x
 
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
+, <-- input (decrease grayscale value)
+, <-- input (decrease grayscale value)
+, <-- input (decrease grayscale value)
+,...,.....
+,.,.,.,,,.
+..,....,,.
+,,.,,...,.
+....,,..,,
+......,.,.
+,...,...,,
+,,,..,,.,,
+....,,...,
+,,.,,,,,,,
 
-1 <-- input (switch multiplexer to output of noise adder)
-\*\*\*\*#\*\*#\*#
-###\*\*\*\*\*\*\*
-\*\*\*\*\*\*\*\*\*\*
-#\*\*######\*
-\*#\*#\*\*\*\*\*\*
-\*\*#\*#\*####
-\*\*##\*\*\*\*#\*
-\*\*\*#\*\*\*\*\*\*
-\*###\*\*\*##\*
-\*\*\*#\*\*\*\*\*#
-
-\*\*\*#\*\*\*\*\*#
-#\*\*#\*#\*#\*\*
-#\*\*##\*\*#\*\*
-\*#\*\*\*\*\*#\*#
-#;#\*\*#\*\*\*#
-\*\*\*\*###\*#\*
-\*\*#\*\*\*####
-\*#\*\*\*\*\*\*\*#
-\*\*######\*\*
-\*\*##\*\*\*##\*
-
-#\*\*\*\*\*\*\*\*\*
-\*\*#\*#\*\*\*#\*
-\*\*#\*\*\*\*\*#\*
-\*#\*\*#\*\*\*#\*
-\*\*\*\*\*#\*\*##
-\*\*\*\*\*\*#\*#\*
-\*\*\*\*#\*\*\*#\*
-\*\*#\*\*\*\*\*\*#
-\*\*\*\*#\*\*\*\*\*
-#\*\*\*######
+0 <-- input (switch mutiplexer back to the generated image)
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
+,,,,,,,,,,
 
-. <-- input (increase grayscale value)
-\*#########
-######\*###
-#######\*$#
-##########
-####$#####
-#####\*####
-#\*##\*#####
-##########
-##\*######\*
-########$#
+, <-- input (decrease grayscale value)
+..........
+..........
+..........
+..........
+..........
+..........
+..........
+..........
+..........
+..........
 
-0 <-- input (switch mutiplexer back to the generated image)
-##########
-##########
-##########
-##########
-##########
-##########
-##########
-##########
-##########
-##########
+1 <-- input (switch multiplexer to output of noise adder)
+. ... ..  
+.   . .   
+..........
+  .  . .. 
+.   . .  .
+  .. .    
+ .  .     
+    ..  . 
+ ..  ..  .
+ ..... .  
 
+q <-- input (exit)
 ]
 
 [endsect]

Copied: sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk (from r41189, /sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk)
==============================================================================
--- /sandbox/SOC/2007/signals/libs/dataflow/doc/introduction.qbk	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/doc/introduction/introduction.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -6,19 +6,23 @@
 as well as some GSoC status updates can be found on the
 [@http://svn.boost.org/trac/boost/wiki/soc/2007/SignalNetwork GSoC page].]
 
-Dataflow is a generic library for [WikiDataflow] programming using various data
-transport mechanisms.  It also has layers of support for
-two data transport mechanisms - one is based on
-[BoostSignals], and the other (experimental and currently broken) is based
-connections made through
-simple object pointers, with support for using [BoostPhoenix2]
-actors for data processing.
-
-The two data transport mechanisms are implemented in the [DataflowSignals]
-and [DataflowPhoenix] layers.  The idea behind providing a generic dataflow
-library is that other data transport mechanisms can be easily adapted for
-use with the library, and benefit from layers built on top of it
-(such as the recently started [DataflowBlueprint] layer).
+Dataflow is a generic library for [WikiDataflow] programming.  It offers:
+
+* a number of generic [concepts] which capture various aspects of a
+dataflow framework.
+* a support layer for a particular dataflow framework ([DataflowSignals]).
+* a framework-independent layer ([DataflowBlueprint]) built on top of the
+  generic layer, which
+  provides dataflow network modeling/analysis via
+  the [BoostGraph], and support for run-time reflection of components.
+  
+The idea behind providing a generic dataflow library is that
+other data transport mechanisms and dataflow frameworks can be easily adapted for
+use with the library, and benefit from layers built on top of the generic layer.
+There is an example on how to do that for [VTK], and there is also an
+implementation of an (experimental and currently broken) layer based
+connections made through simple object pointers, with support for using
+[BoostPhoenix2] actors for data processing ([DataflowPhoenix]).
 
 * If you would like some more information about why one would want to connect
   objects into a dataflow network, read about
@@ -181,13 +185,15 @@
 
 [section:how_to_use How to use this library and the documentation]
 
-The Dataflow library currently has two useful parts:
+The Dataflow library currently has three useful parts:
 
 * A layer providing generic dataflow support, adaptable to various dataflow
-  mechanisms.
+  frameworks and data transport mechanisms.
 * The [DataflowSignals] layer, with a number of implemented components that
   facilitate implementation of dataflow networks using [BoostSignals] as
   a data transport mechanism.
+* The [DataflowBlueprint] layer, built on top of the generic layer and providing
+  runtime reflection and network modeling using the [BoostGraph].
 
 There is also a (currently very experimental) [DataflowPhoenix] layer,
 which uses object pointers with support for
@@ -196,8 +202,8 @@
 [heading Generic dataflow layer]
 
 There are generic properties of dataflow programs which do not depend on the
-data transport mechanism,
-and can be exploited to develop mechanism-independent dataflow code.
+underlying dataflow framework or data transport mechanism,
+and can be exploited to develop generic dataflow code.
 The generic dataflow layer captures some of these properties, and
 has been sucessfully adapted to three
 different data transport mechanisms ([BoostSignals], pointers in conjunction
@@ -208,7 +214,7 @@
 manner. As more generic code is developed on top of
 the generic dataflow layer (such as the recently started [DataflowBlueprint]),
 providing a Dataflow support layer for your
-favorite data transport mechanism will be more beneficial.
+favorite dataflow framework will be more beneficial.
 
 See the [link dataflow.future future directions] of the Dataflow library
 for an idea of what might become available in the future for data transport
@@ -225,23 +231,27 @@
 
 This part of the Dataflow library provides components
 and connection-making capabilty which facilitates large-scale use of
-Boost.Signals as a mechanism to transfer data between processing components.
+[BoostSignals] as a mechanism to transfer data between processing components.
 
 For examples of how the [DataflowSignals] layer can be used, see:
 
 * The example on developing a 
   [link dataflow.introduction.examples.distributed distributed dataflow application].
+* The example on developing an  
+  [link dataflow.introduction.examples.gil image processing network].
 * The [DataflowSignals] documentation.
 
 [heading Dataflow.Blueprint layer]
 
 [DataflowBlueprint] provides run-time reflection and modeling of dataflow
-networks in a BGL graph for any mechanism with implemented Dataflow support.
+networks in a [BoostGraph] graph for any dataflow framework with
+implemented Dataflow library support.
 
 The development of this layer has only begun.  To find out more about it, see:
 
 * The example on [link dataflow.introduction.examples.blueprint run-time
   reflection and connectivity modeling].
+* The [DataflowBlueprint] documentation.
 
 
 [/[heading When to use]
@@ -369,10 +379,15 @@
 
 Version 0.8.1 (under construction)
 
-* started the [DataflowBlueprint] layer (simple runtime reflection and network modeling).
-* expanding the [ComponentConcept] concept (compile-time reflection of ports).
+* Started the [DataflowBlueprint] layer (simple runtime reflection and network modeling).
+* Expanding the [ComponentConcept] concept (compile-time reflection of ports).
 * VTK example Jamfile now works work with Windows (not just Darwin+X11 VTK).
-* provided an example using Boost.GIL.
+* Provided an example using [BoostGIL].
+* The [MechanismConcept] concept is now limited to port-related operations.
+  In the future, an additional tag template parameter might be added to all
+  dataflow templates to allow specifying completely independent dataflow support
+  layers over the same types (the original intent of the [MechanismConcept]
+  parameter).
 
 Version 0.8.0 -
  \[[@http://www.boost-consulting.com/vault/index.php?direction=&order=&directory=Dataflow& available in the Boost vault]\]

Deleted: sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/doc/port_concepts.qbk	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
+++ (empty file)
@@ -1,281 +0,0 @@
-[section PortCategory]
-
-A [PortCategoryConcept] designates a category of port in the Dataflow library.
-The library currently defines two [PortCategoryConcept]s:
-
-* `boost::dataflow::ports::producer`, and
-* `boost::dataflow::ports::consumer`.
-
-For a higher-level overview of the concepts, see the [concepts] introduction.
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[PC] [A [PortCategoryConcept] type.]]
-]
-
-[heading Requirements]
-
-[table
-    [[Name] [Expression] [Result Type] [Description]]
-    [
-        [Opposite PortCategory]
-        [`PC::complement`]
-        [[PortCategoryConcept] type]
-        [
-            The complementing [PortCategoryConcept] of `PC`, meaning that it
-            is possible to make connections between [PortConcept]s of
-            [PortCategoryConcept] `PC` and [PortConcept]s of
-            [PortCategoryConcept] `PC::complement`.
-        ]
-    ]
-]
-
-[heading Header]
-
-The types, templates, and functions shown here are declared in the following
-files:
-
-```
-    #include <boost/dataflow/support/port.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[endsect][/portcategory]
-
-[section PortTraits]
-
-A ['[PortTraitsConcept]] specifies the traits of a [PortConcept].
-
-[heading Notation]
-[variablelist
-    [[PT] [A PortTraits type.]]
-    [[P] [A [PortConcept] type with port traits `PC`.]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Mechanism]
-        [`PT::mechanism`]
-        [any type]
-        [[MechanismConcept] type tag.]
-    ]
-    [
-        [Port Category]
-        [`PT::port_category`]
-        [[PortCategoryConcept] type]
-        [The category of the port]
-    ]
-    [
-        [Port Concept]
-        [`PT::port_concept`]
-        [`concepts::port`, `concepts::keyed_port`]
-        [The most refined producer concept that `P` satisfies.]
-    ]
-]
-
-[heading Header]
-The types, templates, and functions shown here are declared in the following
-files:
-
-```
-    #include <boost/dataflow/support/port.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-The following code defines a port traits type for vtk_algorithm_output,
-and associates it with this type. It is a part of
-the [vtk_example example showing how to provide a VTK support layer].
-
-[vtk_algorithm_output_producer]
-
-[endsect][/porttraits]
-
-
-[section:port Port (ProducerPort, ConsumerPort)]
-
-A type `P` is a ['[PortConcept]] for a mechanism `M` and port category `PC`
-if it specifies a [PortTraitsConcept] for that mechanism and port category.
-
-In that case,
-
-* If `PC` is `ports::producer`, then `P` is a [ProducerPortConcept]
-* If `PC` If `ports::consumer`, then `P` is a [ConsumerPortConcept]
-
-[heading Refinements]
-
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[`P`] [A Port type.]]
-    [[`M`] [A [MechanismConcept] type.]]
-    [[`PC`] [A [PortCategoryConcept] type.]]
-    [[`p`] [An object of type `P`]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Port Traits]
-        [`port_traits_of<M, PC, P>::type`]
-        [Any [PortTraitsConcept] type]
-        [
-            The [PortTraitsConcept] of the port.
-        ]
-    ]
-    [
-        [IsPort Trait]
-        [`is_port<M, PC, P>::type`]
-        [Boolean metafunction that evaluates to true]
-        [
-            A trait encapsulating adherence to the Port
-            concept.
-        ]
-    ]
-    [
-        [Get Port]
-        [`get_port<M,PC>()`]
-        [`get_port_result_type<M,PC,P>::type`]
-        [
-            Returns the underlying port object.  With regular ports,
-            this is typically a reference to `p`.  With [ProxyPortConcept]
-            objects, it is typically the proxied port object.
-        ]
-    ]
-]
-
-[heading Header]
-The types, templates, and functions shown here are declared in the following
-files:
-
-```
-    #include <boost/dataflow/support/port.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-There is an intrusive as well as a non-intrusive way to register the
-[PortTraitsConcept] of a type `P`, thereby making it a [PortConcept].
-
-Non-intrusive registration is done by providing a specialization of
-the `port_traits_of` template (either directly, or through the provided
-macros DATAFLOW_PORT_TRAITS and DATAFLOW_PORT_TRAITS_ENABLE_IF).
-
-Intrusive registration can be done by providing
-a `P::port_traits` member type, which can be either a [PortTraitsConcept]
-type, or an MPL sequence of [PortTraitsConcept] types. Alternatively,
-the Dataflow library provides a convenience class
-`port` which you can inherit instead of declaring the member type.
-
-The below examples illustrate the avaliable registration methods.
-
-[heading Examples]
-
-All of the below examples use the following [MechanismConcept] and
-[PortTraitsConcept] types:
-
-[port_registration_example_prep]
-
-[heading Intrusive registration]
-
-Intrusive registration is the easiest, but assumes you can modify the
-[PortConcept]:
-
-[port_registration_example_intrusive]
-
-[heading Non-intrusive registration]
-
-Non-intrusive registration is done by specializing the `port_traits_of`
-template.  Since the `port_traits_of` template is keyed by [MechanismConcept]
-and [PortCategoryConcept], this is rather verbose:
-
-[port_registration_example_non_intrusive]
-
-To make things simpler, the Dataflow library provides a macro for non-intrusive
-registration (the macro also performs a static check on the
-[PortTraitsConcept]).
-
-[port_registration_example_non_intrusive_macro]
-
-[heading Non-intrusive mass registration]
-
-The `port_traits_of` template has an Enable template parameter for use with
-`boost::enable_if`.  Hence, we can register a number of types at the same time:
-
-[port_registration_example_non_intrusive_enable_if]
-
-And again, there is a convenient macro:
-
-[port_registration_example_non_intrusive_enable_if_macro]
-
-[heading Tests]
-
-With the above registrations, the following tests pass:
-
-[port_registration_check_example]
-
-[endsect][/port]
-
-[section ProxyPortTraits]
-
-
-[endsect][/proxyporttraits]
-
-[section ProxyPort]
-
-A type `PP` is a ['[ProxyPortConcept]] for a mechanism `M` and port category `PC`
-if it specifies a [ProxyPortTraitsConcept] for that mechanism and port category.
-
-If the proxied port type is a valid
-[PortConcept], then 'PP' satisfies the [PortConcept] requirements
-in the same way.
-
-[heading Notation]
-The following expressions are used in this document:
-
-[variablelist
-    [[PP] [A ProxyPort type.]]
-    [[pp] [An object of type `PP`]]
-]
-
-[heading Requirements]
-[table
-    [[Name] [Expression] [Result Type] [Semantics]]
-    [
-        [Proxy Port Traits]
-        [`proxy_port_traits_of<PP>::type`]
-        [[ProxyPortTraitsConcept] type.]
-        [
-            The traits of the proxy port.
-        ]
-    ]
-]
-
-[heading Header]
-The types, templates, and functions shown here are declared in the following
-files:
-
-```
-    #include <boost/dataflow/support/proxy_port.hpp> // or
-    #include <boost/dataflow/support.hpp>
-```
-
-[heading Notes]
-
-[heading Examples]
-
-[endsect][/proxyport]
-
-[section KeyedPort]
-[endsect][/keyed_port]

Modified: sandbox/SOC/2007/signals/libs/dataflow/example/blueprint/blueprint_example.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/example/blueprint/blueprint_example.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/example/blueprint/blueprint_example.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -20,7 +20,7 @@
 
 class blueprint_example
 {
-    typedef blueprint::network<df::signals::mechanism> network_type;
+    typedef blueprint::network network_type;
 
     // The network.
     network_type network;
@@ -47,6 +47,7 @@
         print_port_info("sink_float", sink_float);
         
         // Print some runtime connectability info
+        std::cout << std::endl << "Printing some runtime port connectability info:" << std::endl  << std::endl;
         print_connectability_info("source", source, 0, "sink", sink, 1);
         print_connectability_info("source", source, 1, "sink", sink, 0);
         print_connectability_info("source", source, 0, "sink", sink, 0);
@@ -65,9 +66,9 @@
         ugraph_type g;
         copy_graph(network.graph(), g);
         std::vector<int> component(num_vertices(g));
-        std::cout << std::endl << "Using BGL to analyze the network... There are "
+        std::cout << std::endl << "Using BGL to analyze the network... BGL says there are "
             << connected_components(g, &component[0])
-            << " independent parts of the network." << std::endl << std::endl;
+            << " independent parts of the network!" << std::endl << std::endl;
         
         // Copy the network
         std::cout << "Making a copy of the blueprint." << std::endl << std::endl;
@@ -81,9 +82,10 @@
     void print_port_info(const char *c_name, network_type::component_type c)
     {
         std::cout << "\t" << c_name << " has " << network[c].num_ports() << " ports. " << std::endl;
-        for (int i=0; i<network[c].num_ports(); i++)
+        for (size_t i=0; i<network[c].num_ports(); i++)
             std::cout << "\t\tport " << i << " is a "
-                << (network.get_port(c, i)->traits().category().name()) << std::endl;
+                << (network.get_port(c, i).traits().mechanism().name()) << " "
+                << (network.get_port(c, i).traits().category().name()) << std::endl;
         std::cout << std::endl;
     }
     void print_connectability_info(
@@ -100,11 +102,11 @@
     void output_component_value(
         network_type &network, const char *c_name, typename network_type::component_type c)
     {
-        typedef blueprint::component_t<df::signals::mechanism, signals::storage<void(T)> > & c_type;
-        
+        blueprint::component_t<signals::storage<void(T)> > value;
+        blueprint::extract(network[c].get_port(2), value.get_port(1));
+ 
         std::cout << "\t\tvalue at " << c_name << ":"
-            << static_cast<c_type>(network[c]).get()
-            .template at<0>()
+            << value.get().template at<0>()
             << std::endl;
     }
     void output_component_values(network_type &network)

Modified: sandbox/SOC/2007/signals/libs/dataflow/example/signals/gil_example.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/example/signals/gil_example.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/example/signals/gil_example.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -113,7 +113,7 @@
     static char symbols[8];
 };
 
-char image_display::symbols[8] = {' ', '.', ',', ':', ';', '*', '#', '$' };
+char image_display::symbols[8] = {' ', '.', ',', '-', '+', 'x', 'X', '#'};
 
 //]
 
@@ -133,10 +133,10 @@
             {
             // Keys ',' and '.' adjust the grayscale value
             case ',':
-                adjust(-20);
+                adjust(-32);
                 break;
             case '.':
-                adjust(20);
+                adjust(32);
                 break;
             // Keys '0' and '1' control the mux output
             case '0':
@@ -179,11 +179,11 @@
     signals::timed_generator<void ()> timer;
 
     // Data processor and output:
-    image_generator generator(10,10, 128);
+    image_generator generator(10,10, 32);
     noise_adder filter;
     image_display display;
 
-    controller control(128);
+    controller control(32);
     signals::multiplexer<void (const gil::gray8_image_t &)> mux;
 
     // ---Connect the dataflow network -----------------------------------------
@@ -209,16 +209,16 @@
     control.value_signal >>= generator;
     control.select_signal >>= mux.select_slot();
 
-    // Tell the timer to start producing signals, every 0.5s:
-    timer.enable(0.5);
+    // Tell the timer to start producing signals, every 1.0s:
+    timer.enable(1.0);
 
     // Run the controller
     std::cout
-        << "Use keys ',' and '.' to control the image intensity, "
-        << "and '0' and '1' to switch the display between the unfiltered"
-        << "and filtered image. 'q' will exit." << std::endl
-        << "Since we are using cin for the input, REMEMBER TO PRESS ENTER"
-        << "after each command.";
+        << "Use keys ',' and '.' to control the image intensity, " << std::endl
+        << "and '0' and '1' to switch the display between the unfiltered" << std::endl
+        << "and filtered image. 'q' will exit." << std::endl << std::endl
+        << "Since we are using cin for the input, REMEMBER TO PRESS ENTER" << std::endl
+        << "after each command." << std::endl << std::endl;
     control.run();
 
     timer.join();

Modified: sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_chain.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_chain.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_chain.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -9,7 +9,7 @@
 
 #include <boost/fusion/algorithm/iteration/for_each.hpp>
 #include <boost/fusion/algorithm/transformation/transform.hpp>
-#include <boost/fusion/sequence/generation/make_vector.hpp>
+#include <boost/fusion/include/make_vector.hpp>
 
 #include <boost/test/included/test_exec_monitor.hpp>
 

Modified: sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_disconnect.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_disconnect.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_disconnect.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -21,18 +21,28 @@
             signals::storage<void (float)> floater;
             floater(2.5f);
             signals::storage<void (float)> collector(0.0f);
-
-            banger | counter;
-            floater >>= collector;
-            connect(banger, floater.send_slot());
-/*            
+                        
             banger
                 | counter
-                | (floater >>= collector).send_slot();*/
+                | (floater.send_slot() >>= collector);
             
             banger();
             BOOST_CHECK_EQUAL(counter.count(), 1);
             BOOST_CHECK_EQUAL(collector.at<0>(), 2.5f);
+            
+            #ifndef SIGNAL_NETWORK_THREAD_SAFE
+            BOOST_CHECK((
+                boost::is_base_of<
+                    boost::signals::trackable,
+                    signals::counter<void ()>
+                >::type::value));
+            BOOST_CHECK((
+                boost::is_base_of<
+                    boost::signals::trackable,
+                    signals::storage<void (float)>
+                >::type::value));
+            #endif
+
         } // counter, floater, and collector are now destroyed and disconnected with Boost.Signals
 #ifdef SIGNAL_NETWORK_THREAD_SAFE
         // if [DataflowSignals] has detected thread safe signals, we need to

Modified: sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_socket.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_socket.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/test/signals/test_socket.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -60,7 +60,7 @@
         boost::mutex::scoped_lock lock(mutex_);
         boost::thread t(asio_server);
         cond.wait(lock);
-
+    
         // set up the socket
         asio::ip::tcp::endpoint endpoint_recv(asio::ip::address::from_string("127.0.0.1"), 1097);
         asio::ip::tcp::socket socket(io_service);

Modified: sandbox/SOC/2007/signals/libs/dataflow/test/test_component.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/test/test_component.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/test/test_component.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -4,16 +4,14 @@
 // http://www.boost.org/LICENSE_1_0.txt)
 
 #include <boost/dataflow/support/component_operation.hpp>
-#include <boost/fusion/container/vector/vector.hpp>
+#include <boost/mpl/vector.hpp>
 
 bool invoked = false;
 
 struct my_mechanism;
 
-struct my_component_traits
-{
-    typedef my_mechanism mechanism;
-};
+struct my_component_traits : public boost::dataflow::component_traits<boost::mpl::vector< > >
+{};
 
 struct my_component
 {
@@ -42,7 +40,7 @@
 {
     my_component c;
     
-    df::component_operation<df::operations::invoke, my_mechanism>(c);
+    df::component_operation<df::operations::invoke>(c);
     BOOST_CHECK(invoked);    
     
     return 0;

Modified: sandbox/SOC/2007/signals/libs/dataflow/test/test_port.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/test/test_port.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/test/test_port.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -46,10 +46,10 @@
 
 namespace boost { namespace dataflow {
 
-// port_traits_of holds the PortTraits type of a Port, keyed by Mechanism
+// register_port_traits holds the PortTraits type of a Port, keyed by Mechanism
 // and PortCategory
 template<>
-struct port_traits_of<some_mechanism, df::ports::producer, non_intrusive_port>
+struct register_port_traits<some_mechanism, df::ports::producer, non_intrusive_port>
 {
     typedef producer_traits type;
 };
@@ -79,10 +79,10 @@
 
 namespace boost { namespace dataflow {
 
-// port_traits_of holds the PortTraits type of a Port, keyed by Mechanism
+// register_port_traits holds the PortTraits type of a Port, keyed by Mechanism
 // and PortCategory
 template<typename T>
-struct port_traits_of<
+struct register_port_traits<
     some_mechanism,
     df::ports::producer,
     T,

Modified: sandbox/SOC/2007/signals/libs/dataflow/test/test_reflective_component.cpp
==============================================================================
--- sandbox/SOC/2007/signals/libs/dataflow/test/test_reflective_component.cpp	(original)
+++ sandbox/SOC/2007/signals/libs/dataflow/test/test_reflective_component.cpp	2007-11-27 21:20:28 EST (Tue, 27 Nov 2007)
@@ -3,7 +3,7 @@
 // 1.0. (See accompanying file LICENSE_1_0.txt or copy at
 // http://www.boost.org/LICENSE_1_0.txt)
 
-#include <boost/dataflow/support/reflective_component.hpp>
+#include <boost/dataflow/support/component.hpp>
 //#include <boost/fusion/container/vector/vector.hpp>
 #include <boost/mpl/vector.hpp>
 #include <boost/mpl/int.hpp>
@@ -72,8 +72,8 @@
 {
     my_component c;
     
-    my_consumer &cc = df::get_component_port<my_mechanism, boost::mpl::int_<0> >(c);
-    my_producer &cp = df::get_component_port<my_mechanism, boost::mpl::int_<1> >(c);
+    my_consumer &cc = df::get_component_port<boost::mpl::int_<0> >(c);
+    my_producer &cp = df::get_component_port<boost::mpl::int_<1> >(c);
     
     BOOST_CHECK_EQUAL(&cc, &c.consumer);
     BOOST_CHECK_EQUAL(&cp, &c.producer);