Re: Updated dataflow semantics for RTT

On Tue, 29 Sep 2015, Sylvain Joyeux wrote:

>> 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.

"+1": this "inversion of control" makes a lot of sense! (It is already
available in the 'event stream' paradigm...)

> 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

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