Re: Updated dataflow semantics for RTT

> I do not fully understand these last two points and why these things would
> not already be possible today with RTT 2, perhaps by adding some simple, non
> API-breaking helper methods to port and ConnectionManager classes. It would
> be quite straight-forward to implement a store-and-forward channel element
> that can be installed right after the channel input by the ConnFactory and
> that replaces the current init functionality out of the OutputPort
> implementation, but I do not really see why this would be beneficial or open
> new possibilities for now.

I already knew the place of ConnFactory. The problem *is* that it is
internal and that the three operations I listed are "hidden" behind
the ConnPolicy object. It makes the logic behind ConnPolicy horrible.
By exposing these operations, and making them used by the tooling
(thus deprecating the port API), you actually in effect remove the
issue that RTT::TaskContext is trying to solve too many things. All
the possibilities that policy encodes in a very weird way become
different combinations of the three basic operations.

For instance: yes, you can already internally to ConnFactory replace
the "keep last written" and init stuff. But then you have to extend
the port API *even more*. Every single change / extension to the
connection handling right now requires to change the port API. By
exposing ConnFactory, in effect, you remove that need, and pave the
way for other to replace the connfactory by an extended version that
does more (or different) without requiring even more plugins or
whatnots.

Sylvain
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev