Re: Updated dataflow semantics for RTT

--===============1198201156==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_Pa1XnKBfiF1jiIVHikCHwQ)"


--Boundary_(ID_Pa1XnKBfiF1jiIVHikCHwQ)
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: quoted-printable

=0AOn Sep 28, 2015, at 08:44 AM, Herman Bruyninckx <Herman.Bruyninckx@mech=
.kuleuven.be> wrote:=0A=0AOn Mon, 28 Sep 2015, S Roderick wrote:=0A=0AOn S=
ep 27, 2015, at 08:11 AM, Herman Bruyninckx=0A<[email protected]=
uven.be> wrote:=0A=0AOn Mon, 21 Sep 2015, Johannes Meyer wrote:=0A=0ADear =
Orocos community,=0Aduring the last few weeks we have been working on the =
concept and=0Aimplementation of a major redesign of the Orocos=0ARTT dataf=
low, that we would like to share and ask for your valuable feedback.=0AThe=
re was already a previous=0Adiscussion on the mailing list about the topic=
 earlier this year [1], and the=0Afollowing proposal tries to address=0Aal=
l the issues mentioned there.=0A=0AWith the version 2 of the Orocos toolch=
ain some years ago, the previous data=0Aflow architecture, which was based=
 on a=0Asingle data object and buffer shared between all ports participati=
ng at the=0Asame connection, was replaced by a=0Aconnection architecture b=
ased on data flow, where each pair of output and=0Ainput ports (or streams=
) is connected=0Athrough an individual channel, each having its own data o=
bject or buffer.=0AWhile there was a well substantiated=0Amotivation for t=
his update and it solved some of the shortcomings in RTT=0Aversion 1 [2], =
it also introduced some new,=0Asometimes hidden, problems and broke other =
use cases. One example is an input=0Aport with multiple connections, where=
=0Adue to the ambiguity in which channel to read from the result is someti=
mes=0Aunexpected to the user, who expects that=0Aeach write overwrites pre=
vious samples in case of simple data connections.=0A=0AWe assembled a docu=
ment (see attachment, or [3]) which introduces the version=0A1 and version=
 2 data flow semantics=0Afor those who are not aware of the details, three=
 example use cases and=0Apresents the new dataflow architecture we=0Ahave =
in mind, which ideally works for a superset of use cases that are=0Asuppor=
ted by RTT version 1 and 2.=C2=A0=0A=0AWe do not want to go into details h=
ere, so only a short summary for those who=0Ado not want to read the full =
document:=0AWe propose to add two more boolean flags to the ConnPolicy str=
uct that=0Adescribes the type of connection between two=0Aports: "shared" =
and "mandatory". Furthermore the existing "pull" flag, which=0Awas only me=
aningful for remote=0Aconnections, now has a big influence for local conne=
ctions.=0A=0A"push" vs. "pull"=0A=0A=0AThanks for this nice effort. I thin=
k it is really time to consider a next=0Ageneration of Orocos RTT...=0A=0A=
If you allow me to bring in my two cents... It's possible that you won't l=
ike=0Athe=0Amessage, or find it off-topic, but I think I should share it w=
ith you anyway=E2=80=A6=0A=0AThese are interesting ideas Herman, but=C2=A0=
you're right in that they're somewhat=0Aoff topic. For this discussion we =
are interested in the here and now - in=0Aevolutionary and incremental cha=
nges to a product=C2=A0that has served many of us=0Afairly well.=0A=0AThe =
evolution from the current "data flow architecture" to a "event stream"=0A=
_can_/_could_ be done in an incremental way...=0APolicy by policy. (i.e., =
pull/push; read/write; buffer/port;...) =0ASeparation by separation. (i.e.=
, component/activity/thread/OS; pub/sub to=0Aevent stream;...)=0A=C2=A0=0A=
With all due respect, I think that your idea of "incremental" and mine are=
 two very different things (and both are equally valid). It took us two fu=
ll years to convert our system from RTT v1 to RTT v2. There is no way we w=
ould even consider moving to a RTT replacement without some serious review=
 and up front discover and prototype use of a replacement system. So incre=
mental for us is defined in months to years =E2=80=A6=0A=0APersonally, I'm=
 not so worried about "better" as I am worried=0Aabout "good enough".=0A=0A=
I am mostly interested in "simple". Because that is what determines how=0A=
much of the potential mind share a project actually gets.=0A(Mind that I a=
m not interested in "easy", which is the driver for ROS, and=0Athat serves=
 another public well.)=0A=C2=A0=0A+1 on simple.=0AS=0A=0A=

--Boundary_(ID_Pa1XnKBfiF1jiIVHikCHwQ)
Content-type: multipart/related;
	boundary="Boundary_(ID_uA2HSWHFOkD7gDEknBqWpw)"; type="text/html"


--Boundary_(ID_uA2HSWHFOkD7gDEknBqWpw)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

<html><body><div><br></div><div>On Sep 28, 2015, at 08:44 AM, Herman Bruyninckx &lt;He=
[email protected]&gt; wrote:<br><br></div><div><blockquote =
type=3D"cite"><div class=3D"msg-quote"><div class=3D"_stretch"><span class=
=3D"body-text-content"><span class=3D"body-text-content">On Mon, 28 Sep 20=
15, S Roderick wrote:<br><br></span></span><blockquote class=3D"quoted-pla=
in-text" type=3D"cite">On Sep 27, 2015, at 08:11 AM, Herman Bruyninckx</bl=
ockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">&lt;Herman.=
[email protected]&gt; wrote:</blockquote><blockquote class=3D"qu=
oted-plain-text" type=3D"cite"><br></blockquote><blockquote class=3D"quote=
d-plain-text" type=3D"cite">On Mon, 21 Sep 2015, Johannes Meyer wrote:</bl=
ockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"><br></block=
quote><blockquote class=3D"quoted-plain-text" type=3D"cite">Dear Orocos co=
mmunity,</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"=
>during the last few weeks we have been working on the concept and</blockq=
uote><blockquote class=3D"quoted-plain-text" type=3D"cite">implementation =
of a major redesign of the Orocos</blockquote><blockquote class=3D"quoted-=
plain-text" type=3D"cite">RTT dataflow, that we would like to share and as=
k for your valuable feedback.</blockquote><blockquote class=3D"quoted-plai=
n-text" type=3D"cite">There was already a previous</blockquote><blockquote=
 class=3D"quoted-plain-text" type=3D"cite">discussion on the mailing list =
about the topic earlier this year [1], and the</blockquote><blockquote cla=
ss=3D"quoted-plain-text" type=3D"cite">following proposal tries to address=
</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">all the=
 issues mentioned there.</blockquote><blockquote class=3D"quoted-plain-tex=
t" type=3D"cite"><br></blockquote><blockquote class=3D"quoted-plain-text" =
type=3D"cite">With the version 2 of the Orocos toolchain some years ago, t=
he previous data</blockquote><blockquote class=3D"quoted-plain-text" type=3D=
"cite">flow architecture, which was based on a</blockquote><blockquote cla=
ss=3D"quoted-plain-text" type=3D"cite">single data object and buffer share=
d between all ports participating at the</blockquote><blockquote class=3D"=
quoted-plain-text" type=3D"cite">same connection, was replaced by a</block=
quote><blockquote class=3D"quoted-plain-text" type=3D"cite">connection arc=
hitecture based on data flow, where each pair of output and</blockquote><b=
lockquote class=3D"quoted-plain-text" type=3D"cite">input ports (or stream=
s) is connected</blockquote><blockquote class=3D"quoted-plain-text" type=3D=
"cite">through an individual channel, each having its own data object or b=
uffer.</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">W=
hile there was a well substantiated</blockquote><blockquote class=3D"quote=
d-plain-text" type=3D"cite">motivation for this update and it solved some =
of the shortcomings in RTT</blockquote><blockquote class=3D"quoted-plain-t=
ext" type=3D"cite">version 1 [2], it also introduced some new,</blockquote=
><blockquote class=3D"quoted-plain-text" type=3D"cite">sometimes hidden, p=
roblems and broke other use cases. One example is an input</blockquote><bl=
ockquote class=3D"quoted-plain-text" type=3D"cite">port with multiple conn=
ections, where</blockquote><blockquote class=3D"quoted-plain-text" type=3D=
"cite">due to the ambiguity in which channel to read from the result is so=
metimes</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">=
unexpected to the user, who expects that</blockquote><blockquote class=3D"=
quoted-plain-text" type=3D"cite">each write overwrites previous samples in=
 case of simple data connections.</blockquote><blockquote class=3D"quoted-=
plain-text" type=3D"cite"><br></blockquote><blockquote class=3D"quoted-pla=
in-text" type=3D"cite">We assembled a document (see attachment, or [3]) wh=
ich introduces the version</blockquote><blockquote class=3D"quoted-plain-t=
ext" type=3D"cite">1 and version 2 data flow semantics</blockquote><blockq=
uote class=3D"quoted-plain-text" type=3D"cite">for those who are not aware=
 of the details, three example use cases and</blockquote><blockquote class=
=3D"quoted-plain-text" type=3D"cite">presents the new dataflow architectur=
e we</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">hav=
e in mind, which ideally works for a superset of use cases that are</block=
quote><blockquote class=3D"quoted-plain-text" type=3D"cite">supported by R=
TT version 1 and 2.&nbsp;</blockquote><blockquote class=3D"quoted-plain-te=
xt" type=3D"cite"><br></blockquote><blockquote class=3D"quoted-plain-text"=
 type=3D"cite">We do not want to go into details here, so only a short sum=
mary for those who</blockquote><blockquote class=3D"quoted-plain-text" typ=
e=3D"cite">do not want to read the full document:</blockquote><blockquote =
class=3D"quoted-plain-text" type=3D"cite">We propose to add two more boole=
an flags to the ConnPolicy struct that</blockquote><blockquote class=3D"qu=
oted-plain-text" type=3D"cite">describes the type of connection between tw=
o</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">ports:=
 "shared" and "mandatory". Furthermore the existing "pull" flag, which</bl=
ockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">was only me=
aningful for remote</blockquote><blockquote class=3D"quoted-plain-text" ty=
pe=3D"cite">connections, now has a big influence for local connections.</b=
lockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"><br></bloc=
kquote><blockquote class=3D"quoted-plain-text" type=3D"cite">"push" vs. "p=
ull"</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"><br=
></blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"><br></=
blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">Thanks fo=
r this nice effort. I think it is really time to consider a next</blockquo=
te><blockquote class=3D"quoted-plain-text" type=3D"cite">generation of Oro=
cos RTT...</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cit=
e"><br></blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">=
If you allow me to bring in my two cents... It's possible that you won't l=
ike</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">the<=
/blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">message,=
 or find it off-topic, but I think I should share it with you anyway=E2=80=
=A6</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"><br>=
</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">These a=
re interesting ideas Herman, but&nbsp;you're right in that they're somewha=
t</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">off to=
pic. For this discussion we are interested in the here and now - in</block=
quote><blockquote class=3D"quoted-plain-text" type=3D"cite">evolutionary a=
nd incremental changes to a product&nbsp;that has served many of us</block=
quote><blockquote class=3D"quoted-plain-text" type=3D"cite">fairly well.</=
blockquote><span class=3D"body-text-content"><span class=3D"body-text-cont=
ent"><br>The evolution from the current "data flow architecture" to a "eve=
nt stream"<br>_can_/_could_ be done in an incremental way...<br>Policy by =
policy. (i.e., pull/push; read/write; buffer/port;...) <br>Separation by s=
eparation. (i.e., component/activity/thread/OS; pub/sub to<br>event stream=
;...)</span></span></div></div></blockquote><span>&nbsp;</span></div><div>=
With all due respect, I think that your idea of "incremental" and mine are=
 two very different things (and both are equally valid). It took us two fu=
ll years to convert our system from RTT v1 to RTT v2. There is no way we w=
ould even consider moving to a RTT replacement without some serious review=
 and up front discover and prototype use of a replacement system. So incre=
mental for us is defined in months to years =E2=80=A6</div><div><br></div>=
<div><blockquote type=3D"cite"><div class=3D"msg-quote"><div class=3D"_str=
etch"><blockquote class=3D"quoted-plain-text" type=3D"cite">Personally, I'=
m not so worried about "better" as I am worried</blockquote><blockquote cl=
ass=3D"quoted-plain-text" type=3D"cite">about "good enough".</blockquote><=
span class=3D"body-text-content"><span class=3D"body-text-content"><br>I a=
m mostly interested in "simple". Because that is what determines how<br>mu=
ch of the potential mind share a project actually gets.<br>(Mind that I am=
 not interested in "easy", which is the driver for ROS, and<br>that serves=
 another public well.)</span></span></div></div></blockquote><span>&nbsp;<=
/span></div><div>+1 on simple.</div><div>S</div><div><blockquote type=3D"c=
ite"><div class=3D"msg-quote"><div class=3D"_stretch"><blockquote class=3D=
"quoted-plain-text" type=3D"cite"><br></blockquote></div></div></blockquot=
e></div></body></html>=

--Boundary_(ID_uA2HSWHFOkD7gDEknBqWpw)--

--Boundary_(ID_Pa1XnKBfiF1jiIVHikCHwQ)--

--===============1198201156==
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

--===============1198201156==--