Re: Updated dataflow semantics for RTT

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-492900143-1443444220=:30972
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On Mon, 28 Sep 2015, S Roderick wrote:

> On Sep 27, 2015, at 08:11 AM, Herman Bruyninckx=20
> <[email protected]> wrote:
>
> On Mon, 21 Sep 2015, Johannes Meyer wrote:
>
> Dear Orocos community,
> during the last few weeks we have been working on the concept and=20
> implementation of a major redesign of the Orocos
> RTT dataflow, that we would like to share and ask for your valuable fee=
dback.=20
> There was already a previous
> discussion on the mailing list about the topic earlier this year [1], a=
nd the=20
> following proposal tries to address
> all the issues mentioned there.
>
> With the version 2 of the Orocos toolchain some years ago, the previous=
 data=20
> flow architecture, which was based on a
> single data object and buffer shared between all ports participating at=
 the=20
> same connection, was replaced by a
> connection architecture based on data flow, where each pair of output a=
nd=20
> input ports (or streams) is connected
> through an individual channel, each having its own data object or buffe=
r.=20
> While there was a well substantiated
> motivation for this update and it solved some of the shortcomings in RT=
T=20
> version 1 [2], it also introduced some new,
> sometimes hidden, problems and broke other use cases. One example is an=
 input=20
> port with multiple connections, where
> due to the ambiguity in which channel to read from the result is someti=
mes=20
> unexpected to the user, who expects that
> each write overwrites previous samples in case of simple data connectio=
ns.
>
> We assembled a document (see attachment, or [3]) which introduces the v=
ersion=20
> 1 and version 2 data flow semantics
> for those who are not aware of the details, three example use cases and=
=20
> presents the new dataflow architecture we
> have in mind, which ideally works for a superset of use cases that are=20
> supported by RTT version 1 and 2.=C2=A0
>
> We do not want to go into details here, so only a short summary for tho=
se who=20
> do not want to read the full document:
> We propose to add two more boolean flags to the ConnPolicy struct that=20
> describes the type of connection between two
> ports: "shared" and "mandatory". Furthermore the existing "pull" flag, =
which=20
> was only meaningful for remote
> connections, now has a big influence for local connections.
>
> "push" vs. "pull"
>
>
> Thanks for this nice effort. I think it is really time to consider a ne=
xt
> generation of Orocos RTT...
>
> If you allow me to bring in my two cents... It's possible that you won'=
t like=20
> the
> message, or find it off-topic, but I think I should share it with you a=
nyway=E2=80=A6
>
> These are interesting ideas Herman, but=C2=A0you're right in that they'=
re somewhat=20
> off topic. For this discussion we are interested in the here and now - =
in=20
> evolutionary and incremental changes to a product=C2=A0that has served =
many of us=20
> fairly well.

The evolution from the current "data flow architecture" to a "event strea=
m"
_can_/_could_ be done in an incremental way...
Policy by policy. (i.e., pull/push; read/write; buffer/port;...)=20
Separation by separation. (i.e., component/activity/thread/OS; pub/sub to
event stream;...)

> Personally, I'm not so worried about "better" as I am worried=20
> about "good enough".

I am mostly interested in "simple". Because that is what determines how
much of the potential mind share a project actually gets.
(Mind that I am not interested in "easy", which is the driver for ROS, an=
d
that serves another public well.)

> I'd be interesting in exploring some of what you've said here in=C2=A0a=
nother=20
> discussion.

Fine! :-)

> Cheers
> Stephen

Herman

>
>
--8323329-492900143-1443444220=:30972
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--8323329-492900143-1443444220=:30972--