Re: Updated dataflow semantics for RTT
S Roderick <[email protected]> Mon, 28 Sep 2015 11:36:24 +0000 (GMT)
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0432886247== Content-type: multipart/alternative; boundary="Boundary_(ID_1yZrEpC5hYn42f3E+gAAGg)" --Boundary_(ID_1yZrEpC5hYn42f3E+gAAGg) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On Sep 27, 2015, at 08:11 AM, Herman Bruyninckx <[email protected]= leuven.be> wrote:=0A=0AOn Mon, 21 Sep 2015, Johannes Meyer wrote:=0A=0ADea= r Orocos community,=0Aduring the last few weeks we have been working on th= e concept and implementation of a major redesign of the Orocos=0ARTT dataf= low, that we would like to share and ask for your valuable feedback. There= was already a previous=0Adiscussion on the mailing list about the topic e= arlier this year [1], and the following proposal tries to address=0Aall th= e issues mentioned there.=0A=0AWith the version 2 of the Orocos toolchain = some years ago, the previous data flow architecture, which was based on a=0A= single data object and buffer shared between all ports participating at th= e same connection, was replaced by a=0Aconnection architecture based on da= ta flow, where each pair of output and input ports (or streams) is connect= ed=0Athrough an individual channel, each having its own data object or buf= fer. While there was a well substantiated=0Amotivation for this update and= it solved some of the shortcomings in RTT version 1 [2], it also introduc= ed some new,=0Asometimes hidden, problems and broke other use cases. One e= xample is an input port with multiple connections, where=0Adue to the ambi= guity in which channel to read from the result is sometimes unexpected to = the user, who expects that=0Aeach write overwrites previous samples in cas= e of simple data connections.=0A=0AWe assembled a document (see attachment= , or [3]) which introduces the version 1 and version 2 data flow semantics= =0Afor those who are not aware of the details, three example use cases and= presents the new dataflow architecture we=0Ahave in mind, which ideally w= orks for a superset of use cases that are supported by RTT version 1 and 2= .=C2=A0=0A=0AWe do not want to go into details here, so only a short summa= ry for those who do not want to read the full document:=0AWe propose to ad= d two more boolean flags to the ConnPolicy struct that describes the type = of connection between two=0Aports: "shared" and "mandatory". Furthermore t= he existing "pull" flag, which was only meaningful for remote=0Aconnection= s, now has a big influence for local connections.=0A=0A"push" vs. "pull"=0A= =0A=0AThanks for this nice effort. I think it is really time to consider a= next=0Ageneration of Orocos RTT...=0A=0AIf you allow me to bring in my tw= o cents... It's possible that you won't like the=0Amessage, or find it off= -topic, but I think I should share it with you anyway=E2=80=A6=0A=0AThese = are interesting ideas Herman, but=C2=A0you're right in that they're somewh= at off topic. For this discussion we are interested in the here and now - = in evolutionary and incremental changes to a product=C2=A0that has served = many of us fairly well. Personally, I'm not so worried about "better" as I= am worried about "good enough".=0A=0AI'd be interesting in exploring some= of what you've said here in=C2=A0another discussion.=0A=0ACheers=0AStephe= n=0A=0A= --Boundary_(ID_1yZrEpC5hYn42f3E+gAAGg) Content-type: multipart/related; boundary="Boundary_(ID_0Rv02NFenlPHdBq5DrF6wQ)"; type="text/html" --Boundary_(ID_0Rv02NFenlPHdBq5DrF6wQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable <html><body><div><span style=3D"line-height: 1.5;">On Sep 27, 2015, at 08:11 AM, Herma= n Bruyninckx <[email protected]> wrote:</span></div= ><div><br></div><div><blockquote type=3D"cite"><div class=3D"msg-quote"><d= iv class=3D"_stretch"><span class=3D"body-text-content"><span class=3D"bod= y-text-content">On Mon, 21 Sep 2015, Johannes Meyer wrote:<br><br></span><= /span><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 impleme= ntation of a major redesign of the Orocos</blockquote><blockquote class=3D= "quoted-plain-text" type=3D"cite">RTT dataflow, that we would like to shar= e and ask for your valuable feedback. There was already a previous</blockq= uote><blockquote class=3D"quoted-plain-text" type=3D"cite">discussion on t= he mailing list about the topic earlier this year [1], and the following p= roposal tries to address</blockquote><blockquote class=3D"quoted-plain-tex= t" type=3D"cite">all the issues mentioned there.</blockquote><blockquote c= lass=3D"quoted-plain-text" type=3D"cite"><br></blockquote><blockquote clas= s=3D"quoted-plain-text" type=3D"cite">With the version 2 of the Orocos too= lchain some years ago, the previous data flow architecture, which was base= d on a</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">s= ingle data object and buffer shared between all ports participating at the= same connection, was replaced by a</blockquote><blockquote class=3D"quote= d-plain-text" type=3D"cite">connection architecture based on data flow, wh= ere each pair of output and input ports (or streams) is connected</blockqu= ote><blockquote class=3D"quoted-plain-text" type=3D"cite">through an indiv= idual channel, each having its own data object or buffer. While there was = a well substantiated</blockquote><blockquote class=3D"quoted-plain-text" t= ype=3D"cite">motivation for this update and it solved some of the shortcom= ings in RTT version 1 [2], it also introduced some new,</blockquote><block= quote class=3D"quoted-plain-text" type=3D"cite">sometimes hidden, problems= and broke other use cases. One example is an input port with multiple con= nections, 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 unexpected to the user, who expects that</blockquote><blockquote c= lass=3D"quoted-plain-text" type=3D"cite">each write overwrites previous sa= mples in case of simple data connections.</blockquote><blockquote class=3D= "quoted-plain-text" type=3D"cite"><br></blockquote><blockquote class=3D"qu= oted-plain-text" type=3D"cite">We assembled a document (see attachment, or= [3]) which introduces the version 1 and version 2 data flow semantics</bl= ockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">for those w= ho are not aware of the details, three example use cases and presents the = new dataflow architecture we</blockquote><blockquote class=3D"quoted-plain= -text" type=3D"cite">have in mind, which ideally works for a superset of u= se cases that are supported by RTT version 1 and 2. </blockquote><blo= ckquote class=3D"quoted-plain-text" type=3D"cite"><br></blockquote><blockq= uote class=3D"quoted-plain-text" type=3D"cite">We do not want to go into d= etails here, so only a short summary for those who do not want to read the= full document:</blockquote><blockquote class=3D"quoted-plain-text" type=3D= "cite">We propose to add two more boolean flags to the ConnPolicy struct t= hat describes the type of connection between two</blockquote><blockquote c= lass=3D"quoted-plain-text" type=3D"cite">ports: "shared" and "mandatory". = Furthermore the existing "pull" flag, which was only meaningful for remote= </blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">connect= ions, now has a big influence for local connections.</blockquote><blockquo= te class=3D"quoted-plain-text" type=3D"cite"><br></blockquote><blockquote = class=3D"quoted-plain-text" type=3D"cite">"push" vs. "pull"</blockquote><b= lockquote class=3D"quoted-plain-text" type=3D"cite"><br></blockquote><span= class=3D"body-text-content"><span class=3D"body-text-content"><br>Thanks = for this nice effort. I think it is really time to consider a next<br>gene= ration of Orocos RTT...<br><br>If you allow me to bring in my two cents...= It's possible that you won't like the<br>message, or find it off-topic, b= ut I think I should share it with you anyway=E2=80=A6</span></span></div><= /div></blockquote><span><div><span><br></span></div>These are interesting = ideas Herman, but you're right in that they're somewhat off topic. Fo= r this discussion we are interested in the here and now - in evolutionary = and incremental changes to a product that has served many of us fairl= y well. Personally, I'm not so worried about "better" as I am worried abou= t "good enough".</span></div><div><span><br></span></div><div><span>I'd be= interesting in exploring some of what you've said here in another di= scussion.</span></div><div><span><br></span></div><div><span>Cheers</span>= </div><div><span>Stephen</span></div><div></div><div><blockquote type=3D"c= ite"><div class=3D"msg-quote"><div class=3D"_stretch"><span class=3D"body-= text-content"><br></span></div></div></blockquote></div></body></html>= --Boundary_(ID_0Rv02NFenlPHdBq5DrF6wQ)-- --Boundary_(ID_1yZrEpC5hYn42f3E+gAAGg)-- --===============0432886247== 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 --===============0432886247==--