Re: Updated dataflow semantics for RTT

> I agree with much at the above, and we have similar problems that we've
> solved in similar ways. But there are also huge parts of our system that,
> while "data driven", aren't at all interested in time. The system itself is
> synchronized and time is (largely) irrelevant - everything operates on a
> per-cycle basis. In the long run, we time stamp only a tiny portion of the
> data in our system due to this. Equally valid, but different.

I don't dispute that you probably have a very good point, you usually
do, but could you provide me with a concrete example of such a setup
that uses buffers ? It would really help me grasp the situation.

> Sometimes we want to control whether the network access (and hence
> delay/non-real-time part) is on the writer or reader side. That should be an
> application-level choice.

Agreed, but this choice is currently bundled with having a buffer per
channel or one per input port.

> If you put the buffer per-port, you end up with one policy per port.
> Port-driven triggering (event ports) are governed by the data object
> (i.e. per-port), data object size and type becomes per-port as well.
> What's left in the connection policy is the info necessary to reach
> the other side (i.e. the topic name in ROS), which means that it is
> not a policy anymore but a "remote endpoint"
>
>
> What if you don't use event ports?

How is that relevant ? Are we misunderstanding each other here ?

As I understand the proposal so far, we have: either you pull (hit
network on read, one buffer per channel) or push (not hit network on
read, have a one buffer per port). The middle ground of
one-buffer-per-channel and not hitting network is not covered, and
that's what *greatly* bothers me.

I know you guys probably have a good case here, I am trying very hard
for you to not break mine

> Note the "selectively remove" above - we still want to be able to use
> v2-flow-status type setups within our system.

My understanding of the proposal is that the v2 semantic are not
available anymore. I'm not pushing against what you need, I want you
to not break what I need.

 - what are going to be the options of network/no-network and
placement of buffer ?
 - how can these options be or not be used with a single output /
single input ? Are they mutually exclusive ? Can they be used together
on the same input port ? On the same output port ?

> We have several hundred local connections in our deployers. We have maybe
> less than 10 remote connections.

Again, how is this relevant ? If the policy is specified per-port, you
won't have any "kind-of-sane default" to configure the CORBA
dispatchers with.

> Buffers vs data connections definitely change the flavor of things. The vast
> majority of our connections are data connections, not buffers.

I *know* which leads to this long discussion, because I am on the
completely other end of things: we mostly use buffered connections.

> I think that we're getting off topic as a whole.

I don't think so. So far, my concerns with the proposal are still
there: by getting closer to v1 semantics, the proposal breaks v2
semantics in a way that is fundamental to me. Peter's post actually
leads me to think that this breakage and known and desired, which is
why I am spending so much time trying to get my point across, while I
already have way too much on my plate.

> a) push vs pull, or specifying whether the data/buffer object is on the
> reader or writer side. This is very useful for system designers dealing with
> significant time delay.
> b) private vs shared, whether a connection is per input/output port pair or
> whether the connection is shared between multiple input/output ports.

So far, "private" is defined one buffer *per input port* (change in
semantic) not *per input/output port pair* (current v2 semantic)

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