Re: Updated dataflow semantics for RTT
Janosch Machowinski <[email protected]> Wed, 23 Sep 2015 13:29:38 +0200
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1466027849==
Content-Type: multipart/alternative;
boundary="------------080209090706020008070602"
This is a multi-part message in MIME format.
--------------080209090706020008070602
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Am 23.09.2015 um 00:20 schrieb S Roderick:
>> What you actually want here is a paradigm change. The buffer of the=20
>> input port should not be defined
>> any more by the connection, but by the input port. Using this=20
>> thought, one could go further and
>> infer the connection policy (buffer size / type) automatically.
>
> I will have to disagree here. Sylvain=E2=80=99s got it right - it is a =
system=20
> design issue to deal with connections. I do not want any thing=20
> inferring what type of buffer policy/size/type someone else thinks my=20
> application needs. No one but the system design of any given system=20
> has enough knowledge to make those decisions.
I think we have a misunderstand here. I only try to rephrase the=20
proposal. The proposal states, that there is only
one input buffer, and that all outgoing connections going to this input=20
buffer must match in type / buffer size.
The type of the input buffer is determined by the first connection. To=20
make life easier, one could also turn the
principle around. During deployment time, set the type and size of the=20
input buffer, and as all connecting ports,
going to this port must match anyway, not specify the information there.
>
>> Ahh, I just realized, what is odd about your example. As a design=20
>> principle, a component does not know anything
>> about the connections that are attached to the port. So, if you are a=20
>> robot controller and want to always use
>> the latest sample, you MUST use R.readNewest(x). You just may not=20
>> rely on the fact that the outside world
>> used the correct connection. Actually in this case you get the=20
>> expected behaviour, if the data order is not broken.
>
> Actually, you don=E2=80=99t need to use readNewest(). The problem is th=
at=20
> systems designed with v1 port semantics in mind that use v2 ports end=20
> up coupling the component with the type of connection, as they have to=20
> work around the problem that Johannes so aptly described above (and=20
> that is similar to a problem posted on the ML some time ago).
Could you rephrase the sentence ' The problem is that systems designed=20
with v1 port semantics in mind that use v2 ports end up coupling the=20
component with the type of connection' ? I don't get what you mean.
>>>
>>>
>>> For the creation of shared connections, I would recommend an new
>>> API. The create call
>>> should contain all involved members. This spares us the headache
>>> of tracking buffer sizes
>>> and types around in the code. Also this will simplify the code
>>> logic, as we don't need the lookup.
>>> e.g.
>>> out.connectShared(b.in <http://b.in/>, c.in <http://c.in/>, d.in
>>> <http://d.in/>, policy) ;
>>>
>>>
>>> A new API instead of adding the shared flag to the ConnPolicy?
>> Yes
>
> Could you state the goal of the existing API, and this new API, in a=20
> way that they are orthogonal and not overlapping?
The goal would just be, to have am more explicit interface. A shared=20
connection is fundamental different from a
normal connection. Also the proposal states, that all the policies used=20
to create a shared connection, must match.
This is error prone and hard to track in my eyes. Also it is a bit=20
implicit what happens.
E.g: I just called connect : Hm, did I create a new connection, or was I=20
attached to an existing buffer ?
Janosch
--=20
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik
Universit=C3=A4t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra=C3=9Fe 1
28359 Bremen, Germany
=20
Zentrale: +49 421 178 45-6611
=20
Besuchsadresse der Nebengesch=C3=A4ftstelle:
Robert-Hooke-Stra=C3=9Fe 5
28359 Bremen, Germany
=20
Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: [email protected]
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
--------------080209090706020008070602
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">Am 23.09.2015 um 00:20 schrieb S
Roderick:<br class=3D"">
</div>
<blockquote cite=3D"mid:[email protected]"
type=3D"cite">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""> What yo=
u
actually want here is a paradigm change. The buffer of the
input port should not be defined<br class=3D"">
any more by the connection, but by the input port. Using
this thought, one could go further and <br class=3D"">
infer the connection policy (buffer size / type)
automatically. <br class=3D"">
</div>
</div>
</blockquote>
<div><br class=3D"">
</div>
I will have to disagree here. Sylvain=E2=80=99s got it right - it=
is a
system design issue to deal with connections. I do not want any
thing inferring what type of buffer policy/size/type someone
else thinks my application needs. No one but the system design
of any given system has enough knowledge to make those
decisions.</div>
</blockquote>
I think we have a misunderstand here. I only try to rephrase the
proposal. The proposal states, that there is only<br>
one input buffer, and that all outgoing connections going to this
input buffer must match in type / buffer size.<br>
The type of the input buffer is determined by the first connection.
To make life easier, one could also turn the <br>
principle around. During deployment time, set the type and size of
the input buffer, and as all connecting ports,<br>
going to this port must match anyway, not specify the information
there.<br>
<br>
<blockquote cite=3D"mid:[email protected]"
type=3D"cite">
<div><br class=3D"">
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""> Ahh, I =
just
realized, what is odd about your example. As a design
principle, a component does not know anything<br class=3D""=
>
about the connections that are attached to the port. So,
if you are a robot controller and want to always use <br
class=3D"">
the latest sample, you MUST use R.readNewest(x). You just
may not rely on the fact that the outside world<br
class=3D"">
used the correct connection. Actually in this case you get
the expected behaviour, if the data order is not broken. </=
div>
</div>
</blockquote>
<div><br class=3D"">
</div>
Actually, you don=E2=80=99t need to use readNewest(). The problem=
is
that systems designed with v1 port semantics in mind that use v2
ports end up coupling the component with the type of connection,
as they have to work around the problem that Johannes so aptly
described above (and that is similar to a problem posted on the
ML some time ago).</div>
</blockquote>
Could you rephrase the sentence ' The problem is that systems
designed with v1 port semantics in mind that use v2 ports end up
coupling the component with the type of connection' ? I don't get
what you mean. <br>
<blockquote cite=3D"mid:[email protected]"
type=3D"cite">
<div>
<blockquote type=3D"cite" class=3D"">
<div class=3D"">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">
<blockquote
cite=3D"mid:[email protected]=
l.com"
type=3D"cite" class=3D"">
<div dir=3D"ltr" class=3D"">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0=
px
0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D=
"">
<div class=3D""> <br class=3D"">
For the creation of shared connections, I
would recommend an new API. The create call<b=
r
class=3D"">
should contain all involved members. This
spares us the headache of tracking buffer
sizes<br class=3D"">
and types around in the code. Also this will
simplify the code logic, as we don't need
the lookup.<br class=3D"">
e.g. <br class=3D"">
out.connectShared(<a moz-do-not-send=3D"true"
href=3D"http://b.in/" target=3D"_blank"
class=3D"">b.in</a>, <a
moz-do-not-send=3D"true" href=3D"http://c.i=
n/"
target=3D"_blank" class=3D"">c.in</a>, <a
moz-do-not-send=3D"true" href=3D"http://d.i=
n/"
target=3D"_blank" class=3D"">d.in</a>, poli=
cy)
;<br class=3D"">
</div>
</div>
</blockquote>
<div class=3D""><br class=3D"">
</div>
<div class=3D"">A new API instead of adding the
shared flag to the ConnPolicy?</div>
</div>
</div>
</div>
</blockquote>
Yes<br class=3D"">
</div>
</div>
</blockquote>
<div><br class=3D"">
</div>
Could you state the goal of the existing API, and this new API,
in a way that they are orthogonal and not overlapping?</div>
</blockquote>
The goal would just be, to have am more explicit interface. A shared
connection is fundamental different from a<br>
normal connection. Also the proposal states, that all the policies
used to create a shared connection, must match.<br>
This is error prone and hard to track in my eyes. Also it is a bit
implicit what happens. <br>
E.g: I just called connect : Hm, did I create a new connection, or
was I attached to an existing buffer ?<br>
=C2=A0=C2=A0=C2=A0 Janosch<br>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik
Universit=C3=A4t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra=C3=9Fe 1
28359 Bremen, Germany
=20
Zentrale: +49 421 178 45-6611
=20
Besuchsadresse der Nebengesch=C3=A4ftstelle:=20
Robert-Hooke-Stra=C3=9Fe 5
28359 Bremen, Germany
=20
Tel.: +49 421 178 45-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:jmachowins=
[email protected]">[email protected]</a>
Weitere Informationen: <a class=3D"moz-txt-link-freetext" href=3D"http:/=
/www.informatik.uni-bremen.de/robotik">http://www.informatik.uni-bremen.d=
e/robotik</a>
</pre>
</body>
</html>
--------------080209090706020008070602--
--===============1466027849==
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
--===============1466027849==--