Re: Updated dataflow semantics for RTT

On 29/9/15, 01:44, "[email protected] on behalf of
Sylvain Joyeux" <[email protected] on behalf of
[email protected]> wrote:

>Hi Johannes, thanks for the long explanation.
>
>On the implementation side, this whole discussion revived an idea I
>have had a while ago, and is pretty much in line with the discussion
>Herman started.
>
>Basically, one could get rid of (a.k.a. "deprecate" of course) the
>connection API on the ports themselves, and replace it by a separate
>object (let's call it "ConnectionManager") which would be in charge of
>managing all these buffers and create all these connections and
>implement the . In its simplest form, each process would have one of
>these objects.
>
>The basic operations it would have support are:
> - create/remove storage object (data object / buffer object)
> - connect output port to storage object
> - connect storage object to input port
>
>A "pull" connection would involve the ConnectionManager of the output
>port. A "push" connection the ConnectionManager of the receiving side.
>How one gets shared or private (or mixed) connections is obvious.
>Flags would be split between the two halves (which is good !). For
>instance, 'init' only affects the output->buffer side.
>
>In principle -- but that's a principle that even I take with a big
>grain of salt given that I did not seriously touch that stuff for
>years -- the current underlying API (creation of the two channel
>halves) would be reused. In other words, only where the connections
>are created would change, not how they are created.
>
>On top of that, it's trivial to create higher-level, easier-to-use
>APIs, and also implement the current connection API so as to not break
>existing code.
>
>It would open the path to a lot of interesting things:
> - finally have a decent way to monitor the data objects (i.e. buffer
>fill rates, "data loss", data counters, that kind of thing). It would
>also make obvious how one could replace the RTT "base connection
>manager" by something else without touching the components. It would
>spell how wonderfully relevant RTT still is to those who don't see it
>;-)
> - if we add the possibility of inter-ConnectionManager connections
>would allow us to move the keepSample functionalities of OutputPort
>out of it, which would also make the whole init functionality a lot
>more transparent. It would allow to expose (and monitor ...) the CORBA
>dispatchers.
>
>Now, I do understand that it might sound "blue sky" and that you might
>not have the time for that ... just sayin' ;-)
>
>Sylvain

What would the advantage of the above connection manager object be over
providing the same functionality (monitoring, etc.) in individual port
objects?

Geoff

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