I finally managed to get a feeling of the difference between properties
and everything else, but I still can't get the difference between
attributes and data ports. They are basically the same from my point of
view (no ?). Actually, the example in the component's builder guide lead
me to think that there is no difference at all :P
Could someone clarify this for me ?
Difference between property, attributes and data ports
On Mon, 29 Sep 2008, Sylvain Joyeux wrote:
> I finally managed to get a feeling of the difference between properties
> and everything else, but I still can't get the difference between
> attributes and data ports. They are basically the same from my point of
> view (no ?). Actually, the example in the component's builder guide lead
> me to think that there is no difference at all :P
>
> Could someone clarify this for me ?
>
I think attributes and properties are the same :-) The names come the
distinction that some CS literature makes:
- attributes: are _given_ by the human to an object
- properties: are _natural_ aspects of an object.
In Orocos, there is no need to make this distinction, I think...
(Also the CS interpretations are not as strict as described above:
Data ports are different, or at least _could_ be used differently:
properties are set/get synchronously, while data ports _can_ be given a
asynchronous policy (buffers of different types) to decouple the exchange
of data between concurrent processes.
Herman
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
RE: Difference between property, attributes and dataports
> -----Original Message-----
> From: orocos-dev-bounces [..] ... [mailto:orocos-dev-
> bounces [..] ...] On Behalf Of Herman Bruyninckx
> Sent: maandag 29 september 2008 18:02
> To: Sylvain Joyeux
> Cc: orocos-dev [..] ...
> Subject: Re: [Orocos-Dev] Difference between property, attributes and
> dataports
>
> On Mon, 29 Sep 2008, Sylvain Joyeux wrote:
>
> > I finally managed to get a feeling of the difference between
properties
> > and everything else, but I still can't get the difference between
> > attributes and data ports. They are basically the same from my point
of
> > view (no ?). Actually, the example in the component's builder guide
lead
> > me to think that there is no difference at all :P
> >
> > Could someone clarify this for me ?
> >
> I think attributes and properties are the same :-) The names come the
> distinction that some CS literature makes:
> - attributes: are _given_ by the human to an object
> - properties: are _natural_ aspects of an object.
> In Orocos, there is no need to make this distinction, I think...
> (Also the CS interpretations are not as strict as described above:
>
>
>
> Data ports are different, or at least _could_ be used differently:
> properties are set/get synchronously, while data ports _can_ be given
a
> asynchronous policy (buffers of different types) to decouple the
exchange
> of data between concurrent processes.
>
See http://www.orocos.org/documents/OrocosIn3Slides.pdf page 2.
It describes an Orocos component's interface. You can see there is a
'Data Flow' and a 'Configuration Interface'. As you can see in the next
slide Data Ports are used connect Components to each other.
In other words:
- DataPorts are for real-time communication between Components.
- Properties are for configuration of individual components.
- Attributes, in my opinion are for Inspection. For example: the
feedback (read only) of a sensor measurement to the user.
A novice user may be tempted to use Properties and Attributes for
communication between Components but this is bad idea. They are not
guaranteed to be thread safe, DataPorts are.
Sander.
Difference between property, attributes and dataports
> A novice user may be tempted to use Properties and Attributes for
> communication between Components but this is bad idea. They are not
> guaranteed to be thread safe, DataPorts are.
I'm actually tempted to use DataPort instead of Attribute, because if
by exporting some information only through Attribute, you actually
assume that that information will never be useful to any of your peers.
That is IMO bad.
That was what I said: I totally understand the usefulness of Property,
but I still really fail to see what Attribute is useful for.
Difference between property, attributes and dataports
On Tuesday 30 September 2008 11:06:53 Sylvain Joyeux wrote:
> > A novice user may be tempted to use Properties and Attributes for
> > communication between Components but this is bad idea. They are not
> > guaranteed to be thread safe, DataPorts are.
>
> I'm actually tempted to use DataPort instead of Attribute, because if
> by exporting some information only through Attribute, you actually
> assume that that information will never be useful to any of your peers.
Exactly !!! Keep that conclusion...
> That is IMO bad.
>
> That was what I said: I totally understand the usefulness of Property,
> but I still really fail to see what Attribute is useful for.
I know it's all my fault, but one of the reasons attributes exist is to
exchange information within the component, for example, between a script and
the C++ code. If you declare a 'var' in a script, it becomes an Attribute
and, likewise, if you create an Attribute in C++, it becomes available as a
var in a script.
We don't have private/public interfaces, so yes, the attribute may be
inspected by outsiders. That's powerful for debugging, but don't depend on it
in your 'data flow' architecture. Use data ports for robust exchange.
So far theory... In reality, we *also* use attributes (and RTT::Constant) for
allowing to influence a component's behaviour (ie tuning a non-persistent
parameter) or have readouts of internal data without setting up a port.
Look at the Deployer for example, it has a constant attribute
ORO_HIGHEST_PRIORITY. In another component, we had an attribute that was an
error count. You could have put the latter in the data flow, but the
architecture didn't require that. It's not a water-thight proof for needing
attributes,and maybe the 'everything is a dataport' meme would make life
easier...but it's overkill for the 'internal communication' purpose.
I remember also that we once had a discussion about the non-consistent API. An
attribute allows a = 10.0 , while a data port required a.Set(10.0)... I'm not
sure this was a good choice...
Peter
Difference between property, attributes and dataports
On Sep 30, 2008, at 08:03 , Peter Soetens wrote:
> On Tuesday 30 September 2008 11:06:53 Sylvain Joyeux wrote:
>>>
>> That is IMO bad.
>>
>> That was what I said: I totally understand the usefulness of
>> Property,
>> but I still really fail to see what Attribute is useful for.
>
> I know it's all my fault, but one of the reasons attributes exist is
> to
> exchange information within the component, for example, between a
> script and
> the C++ code. If you declare a 'var' in a script, it becomes an
> Attribute
> and, likewise, if you create an Attribute in C++, it becomes
> available as a
> var in a script.
>
> We don't have private/public interfaces, so yes, the attribute may be
> inspected by outsiders. That's powerful for debugging, but don't
> depend on it
> in your 'data flow' architecture. Use data ports for robust exchange.
> So far theory... In reality, we *also* use attributes (and
> RTT::Constant) for
> allowing to influence a component's behaviour (ie tuning a non-
> persistent
> parameter) or have readouts of internal data without setting up a
> port.
It was only after 6 months of using Orocos that I discovered this very
useful reason for attributes. Sigh ... :-(
>
> Look at the Deployer for example, it has a constant attribute
> ORO_HIGHEST_PRIORITY. In another component, we had an attribute that
> was an
> error count. You could have put the latter in the data flow, but the
> architecture didn't require that. It's not a water-thight proof for
> needing
> attributes,and maybe the 'everything is a dataport' meme would make
> life
> easier...but it's overkill for the 'internal communication' purpose.
>
> I remember also that we once had a discussion about the non-
> consistent API. An
> attribute allows a = 10.0 , while a data port required
> a.Set(10.0)... I'm not
> sure this was a good choice...
This one gets me all the time, and I end up having to try "=" and then
"Set" ... sigh ... although a similar inconsistency exists on the C++
side also (this was discussed in another thread recently), with Get/
Set, get/set, value/rvalue, etc. It sounds like there was a reason for
this when initially implemented, but is the distinction still valid?
S
Difference between property, attributes and dataports
On Tue, 30 Sep 2008, Sylvain Joyeux wrote:
>> A novice user may be tempted to use Properties and Attributes for
>> communication between Components but this is bad idea. They are not
>> guaranteed to be thread safe, DataPorts are.
> I'm actually tempted to use DataPort instead of Attribute, because if
> by exporting some information only through Attribute, you actually
> assume that that information will never be useful to any of your peers.
Indeed.
> That is IMO bad.
That depends on the context of the application, of course.
Modern, complex systems will indeed need the functionality to let one peer
_influence_ the behaviour of another peer. (And in my view, properties are
exactly the mechanism with which to determine the behaviour of one
component.) But I think the most robust way to do this property updating
between peer components is as follows: the "requesting" peer sends its
"property request update" via a Command that wraps this request into
something that can wait and block, and it's the "receiving" peer that
processes this Command when it is ready to do so, and than sets its local
property in the traditional way. (Or chooses _not_ to follow the request!)
Allowing one peer to adapt _properties_ on another via DataPorts (that, is
without cooperation of the receiving peer) peer violates the "every
component is responsible for its own behaviour" design criteria that
underlies robust multi-component architectures...
This approach is also in correspondence with SoA (Service Oriented
Architectures) in non-control applications, of which several
implementations exist "out there".
> That was what I said: I totally understand the usefulness of Property,
> but I still really fail to see what Attribute is useful for.
Me too :-)
Herman
RE: Difference between property, attributes and dataports
> Modern, complex systems will indeed need the functionality to let one
peer
> _influence_ the behaviour of another peer. (And in my view, properties
are
> exactly the mechanism with which to determine the behaviour of one
> component.) But I think the most robust way to do this property
updating
> between peer components is as follows: the "requesting" peer sends its
> "property request update" via a Command that wraps this request into
> something that can wait and block, and it's the "receiving" peer that
> processes this Command when it is ready to do so, and than sets its
local
> property in the traditional way. (Or chooses _not_ to follow the
request!)
>
This is interesting. This allows Properties to be updated in a
thread-safe way. It makes me wonder why I should continue using
Properties? I could define a set command and a get method for each
Property instead.
> Allowing one peer to adapt _properties_ on another via DataPorts
(that, is
> without cooperation of the receiving peer) peer violates the "every
> component is responsible for its own behaviour" design criteria that
> underlies robust multi-component architectures...
>
It is also not efficient. It requires the component to poll the
"Property" DataPort each tick and evaluate its contents to see if there
is some action required.
Sander.
RE: Difference between property, attributes and dataports
On Tue, 30 Sep 2008, Vandenbroucke Sander wrote:
>> Modern, complex systems will indeed need the functionality to let one
> peer
>> _influence_ the behaviour of another peer. (And in my view, properties
> are
>> exactly the mechanism with which to determine the behaviour of one
>> component.) But I think the most robust way to do this property
> updating
>> between peer components is as follows: the "requesting" peer sends its
>> "property request update" via a Command that wraps this request into
>> something that can wait and block, and it's the "receiving" peer that
>> processes this Command when it is ready to do so, and than sets its
> local
>> property in the traditional way. (Or chooses _not_ to follow the
> request!)
> This is interesting. This allows Properties to be updated in a
> thread-safe way. It makes me wonder why I should continue using
> Properties? I could define a set command and a get method for each
> Property instead.
My suggestion is _not_ to remove properties, but to use them only within a
known thread context. And to do property setting between Components in a
thread-safe way, that is via Commands; but the latter thing is a _policy_,
not a mechanism.
And I think what holds for "set" (wrt thread-safety) also holds for "get"...
>> Allowing one peer to adapt _properties_ on another via DataPorts
> (that, is
>> without cooperation of the receiving peer) peer violates the "every
>> component is responsible for its own behaviour" design criteria that
>> underlies robust multi-component architectures...
>>
> It is also not efficient. It requires the component to poll the
> "Property" DataPort each tick and evaluate its contents to see if there
> is some action required.
...unless we add the functionality that DataPorts can generate events, that
can 'wake up' the component. (This was discussed in another thread
recently.)
Herman
Difference between property, attributes and dataports
On Tue, 30 Sep 2008, Sylvain Joyeux wrote:
>> A novice user may be tempted to use Properties and Attributes for
>> communication between Components but this is bad idea. They are not
>> guaranteed to be thread safe, DataPorts are.
> I'm actually tempted to use DataPort instead of Attribute, because if
> by exporting some information only through Attribute, you actually
> assume that that information will never be useful to any of your peers.
> That is IMO bad.
>
> That was what I said: I totally understand the usefulness of Property,
> but I still really fail to see what Attribute is useful for.
HTH,
Klaas
Difference between property, attributes and data ports
On Monday, September 29, 2008, at 11:47AM, "Sylvain Joyeux" <sylvain [dot] joyeux [..] ...> wrote:
>I finally managed to get a feeling of the difference between properties
>and everything else, but I still can't get the difference between
>attributes and data ports. They are basically the same from my point of
>view (no ?). Actually, the example in the component's builder guide lead
>me to think that there is no difference at all :P
>
>Could someone clarify this for me ?
Properties are local to a component. Data ports allow data to be transferred between components (local and/or remote). Properties are also loaded at runtime with values read from XML configuration files, while data ports are not.
Go back over Section 3 in The Orocos Component Builder's Manual. It does a good job of explaining the differences.
http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/v1.4.x/doc-xml/orocos-components-manual.html#id2622476
HTH
S