Dear Orocos users,
I was wondering whether there is a way to check (i.e. execute a
function/callback) each time a property is changed, or i have to do it
in the update loop (of a periodic component)?
By the way, when I change a property of a periodically running
component, i suppose that a property change will never be reflected in
the middle of an updateHook, right?, or have to copy the variable
locally, in order to be sure that it maintains the same value for a
whole iteration?
Thanks, Gianni.
Check properties input
| Submitted by gianni borghesan on Thu, 2011-10-13 12:40 |
Check properties input
On 10/13/2011 02:35 PM, gianni borghesan wrote:
> Dear Orocos users,
> I was wondering whether there is a way to check (i.e. execute a
> function/callback) each time a property is changed, or i have to do it
> in the update loop (of a periodic component)?
> By the way, when I change a property of a periodically running
> component, i suppose that a property change will never be reflected in
> the middle of an updateHook, right?, or have to copy the variable
> locally, in order to be sure that it maintains the same value for a
> whole iteration?
The property interface is *not* thread safe, so changing a property
while the component is running is dangerous.
If you want to change components dynamically, you must define a setter
operation.
Check properties input
On Thu, Oct 13, 2011 at 02:42:30PM +0200, Sylvain Joyeux wrote:
> On 10/13/2011 02:35 PM, gianni borghesan wrote:
> > Dear Orocos users,
> > I was wondering whether there is a way to check (i.e. execute a
> > function/callback) each time a property is changed, or i have to do it
> > in the update loop (of a periodic component)?
> > By the way, when I change a property of a periodically running
> > component, i suppose that a property change will never be reflected in
> > the middle of an updateHook, right?, or have to copy the variable
> > locally, in order to be sure that it maintains the same value for a
> > whole iteration?
> The property interface is *not* thread safe, so changing a property
> while the component is running is dangerous.
>
> If you want to change components dynamically, you must define a setter
> operation.
Or just use a Port! If you add it as an EventPort it you will also get
notified via updateHook...
Markus
Check properties input
> Or just use a Port! If you add it as an EventPort it you will also get
> notified via updateHook...
Which is then not a property. Property == configuration, Ports == dataflow.
(For the record: I'm discouraging dynamically changing properties, but
some people unfortunately do want that ...)
Sylvain
Check properties input
On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
>
> > Or just use a Port! If you add it as an EventPort it you will also get
> > notified via updateHook...
> Which is then not a property. Property == configuration, Ports == dataflow.
Property=static configuration, Ports=dataflow and dynamic
configuration. Users too often misuse Properties for dynamic stuff
because it somehow seems more appropriate for configuration than a
port.
> (For the record: I'm discouraging dynamically changing properties, but
> some people unfortunately do want that ...)
You can't discourage dynamically changing properties, they are an
inherent charateristic of a component. You can only discourage calling
them "Properties".
Markus
Check properties input
On 10/14/2011 04:38 PM, Markus Klotzbuecher wrote:
> On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
>>> Or just use a Port! If you add it as an EventPort it you will also get
>>> notified via updateHook...
>> Which is then not a property. Property == configuration, Ports == dataflow.
> Property=static configuration, Ports=dataflow and dynamic
> configuration. Users too often misuse Properties for dynamic stuff
> because it somehow seems more appropriate for configuration than a
> port.
>> (For the record: I'm discouraging dynamically changing properties, but
>> some people unfortunately do want that ...)
> You can't discourage dynamically changing properties, they are an
> inherent charateristic of a component. You can only discourage calling
> them "Properties".
I can't disagree more
I personally find that having a "Configuration" interface which is
different from the "Dataflow" (== Communication ?) interface is a good
thing. Having people send configuration parameters through data ports
breaks that assumption, which makes tooling on top of it very hard.
Check properties input
On Fri, Oct 14, 2011 at 05:37:41PM +0200, Sylvain Joyeux wrote:
> On 10/14/2011 04:38 PM, Markus Klotzbuecher wrote:
> > On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
> >>> Or just use a Port! If you add it as an EventPort it you will also get
> >>> notified via updateHook...
> >> Which is then not a property. Property == configuration, Ports == dataflow.
> > Property=static configuration, Ports=dataflow and dynamic
> > configuration. Users too often misuse Properties for dynamic stuff
> > because it somehow seems more appropriate for configuration than a
> > port.
>
> >> (For the record: I'm discouraging dynamically changing properties, but
> >> some people unfortunately do want that ...)
> > You can't discourage dynamically changing properties, they are an
> > inherent charateristic of a component. You can only discourage calling
> > them "Properties".
> I can't disagree more
>
> I personally find that having a "Configuration" interface which is
> different from the "Dataflow" (== Communication ?) interface is a good
> thing. Having people send configuration parameters through data ports
> breaks that assumption, which makes tooling on top of it very hard.
I'm fine with a having a (static) configuration interface using
Properties. But for anything that is supposed to change at runtime,
the border between DataFlow and Configuration is blurred. In that case
I prefer using a Port instead of having to manually do locking etc as
with a method. I also don't see why using a Port should complicate
tooling?
Markus
Check properties input
On 10/14/2011 09:09 PM, Markus Klotzbuecher wrote:
> On Fri, Oct 14, 2011 at 05:37:41PM +0200, Sylvain Joyeux wrote:
>> On 10/14/2011 04:38 PM, Markus Klotzbuecher wrote:
>>> On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
>>>>> Or just use a Port! If you add it as an EventPort it you will also get
>>>>> notified via updateHook...
>>>> Which is then not a property. Property == configuration, Ports == dataflow.
>>> Property=static configuration, Ports=dataflow and dynamic
>>> configuration. Users too often misuse Properties for dynamic stuff
>>> because it somehow seems more appropriate for configuration than a
>>> port.
>>>> (For the record: I'm discouraging dynamically changing properties, but
>>>> some people unfortunately do want that ...)
>>> You can't discourage dynamically changing properties, they are an
>>> inherent charateristic of a component. You can only discourage calling
>>> them "Properties".
>> I can't disagree more
>>
>> I personally find that having a "Configuration" interface which is
>> different from the "Dataflow" (== Communication ?) interface is a good
>> thing. Having people send configuration parameters through data ports
>> breaks that assumption, which makes tooling on top of it very hard.
> I'm fine with a having a (static) configuration interface using
> Properties. But for anything that is supposed to change at runtime,
> the border between DataFlow and Configuration is blurred. In that case
> I prefer using a Port instead of having to manually do locking etc as
> with a method. I also don't see why using a Port should complicate
> tooling?
First, you don't need to do locking while using operations. Just ask RTT
to execute the operation in the task activity.
For the tooling: you end up having "configuration values that go on
ports" and "configuration values that go on properties". You therefore
need, at the tooling level, to build an abstraction that removes that
distinction from the user p.o.v.. Moreover, using ports forbids you to
have a synchronous view on configuration updates since ports are "fire
and forget" (you don't know when the configuration value got written),
while properties are synchronous (you know). This latter point is really
a showstopper for me.
Check properties input
On 10/17/2011 11:29 AM, Sylvain Joyeux wrote:
> On 10/14/2011 09:09 PM, Markus Klotzbuecher wrote:
>> On Fri, Oct 14, 2011 at 05:37:41PM +0200, Sylvain Joyeux wrote:
>>> On 10/14/2011 04:38 PM, Markus Klotzbuecher wrote:
>>>> On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
>>>>>> Or just use a Port! If you add it as an EventPort it you will also get
>>>>>> notified via updateHook...
>>>>> Which is then not a property. Property == configuration, Ports == dataflow.
>>>> Property=static configuration, Ports=dataflow and dynamic
>>>> configuration. Users too often misuse Properties for dynamic stuff
>>>> because it somehow seems more appropriate for configuration than a
>>>> port.
>>>>> (For the record: I'm discouraging dynamically changing properties, but
>>>>> some people unfortunately do want that ...)
>>>> You can't discourage dynamically changing properties, they are an
>>>> inherent charateristic of a component. You can only discourage calling
>>>> them "Properties".
>>> I can't disagree more
>>>
>>> I personally find that having a "Configuration" interface which is
>>> different from the "Dataflow" (== Communication ?) interface is a good
>>> thing. Having people send configuration parameters through data ports
>>> breaks that assumption, which makes tooling on top of it very hard.
>> I'm fine with a having a (static) configuration interface using
>> Properties. But for anything that is supposed to change at runtime,
>> the border between DataFlow and Configuration is blurred. In that case
>> I prefer using a Port instead of having to manually do locking etc as
>> with a method. I also don't see why using a Port should complicate
>> tooling?
> First, you don't need to do locking while using operations. Just ask RTT
> to execute the operation in the task activity.
>
> For the tooling: you end up having "configuration values that go on
> ports" and "configuration values that go on properties". You therefore
> need, at the tooling level, to build an abstraction that removes that
> distinction from the user p.o.v.. Moreover, using ports forbids you to
> have a synchronous view on configuration updates since ports are "fire
> and forget" (you don't know when the configuration value got written),
> while properties are synchronous (you know). This latter point is really
> a showstopper for me.
Oh, and finally you will probably need to devise a way to tell the
property abstraction which transport it should use. Make sure you have a
transport that does not allow missing updates (you definitely don't want
to miss a configuration update).
On the upside of operations: the component designer can choose to reject
updates if the new value is inconsistent *and* report it to the tooling
(more changes would be needed if you were to use ports).
Check properties input
In conclusion (I guess...), the neat way to change a
"dynamical-adjustable property" is to use an operation (OwnThread) to
set it, after check.
What about having its value shown on the component interface (i.e. to
see its value with an ls), but of course without having the possibility
of write it?
or I have to write another operation that just returns the value?
Il giorno lun, 17/10/2011 alle 11.33 +0200, Sylvain Joyeux ha scritto:
> On 10/17/2011 11:29 AM, Sylvain Joyeux wrote:
> > On 10/14/2011 09:09 PM, Markus Klotzbuecher wrote:
> >> On Fri, Oct 14, 2011 at 05:37:41PM +0200, Sylvain Joyeux wrote:
> >>> On 10/14/2011 04:38 PM, Markus Klotzbuecher wrote:
> >>>> On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
> >>>>>> Or just use a Port! If you add it as an EventPort it you will also get
> >>>>>> notified via updateHook...
> >>>>> Which is then not a property. Property == configuration, Ports == dataflow.
> >>>> Property=static configuration, Ports=dataflow and dynamic
> >>>> configuration. Users too often misuse Properties for dynamic stuff
> >>>> because it somehow seems more appropriate for configuration than a
> >>>> port.
> >>>>> (For the record: I'm discouraging dynamically changing properties, but
> >>>>> some people unfortunately do want that ...)
> >>>> You can't discourage dynamically changing properties, they are an
> >>>> inherent charateristic of a component. You can only discourage calling
> >>>> them "Properties".
> >>> I can't disagree more
> >>>
> >>> I personally find that having a "Configuration" interface which is
> >>> different from the "Dataflow" (== Communication ?) interface is a good
> >>> thing. Having people send configuration parameters through data ports
> >>> breaks that assumption, which makes tooling on top of it very hard.
> >> I'm fine with a having a (static) configuration interface using
> >> Properties. But for anything that is supposed to change at runtime,
> >> the border between DataFlow and Configuration is blurred. In that case
> >> I prefer using a Port instead of having to manually do locking etc as
> >> with a method. I also don't see why using a Port should complicate
> >> tooling?
> > First, you don't need to do locking while using operations. Just ask RTT
> > to execute the operation in the task activity.
> >
> > For the tooling: you end up having "configuration values that go on
> > ports" and "configuration values that go on properties". You therefore
> > need, at the tooling level, to build an abstraction that removes that
> > distinction from the user p.o.v.. Moreover, using ports forbids you to
> > have a synchronous view on configuration updates since ports are "fire
> > and forget" (you don't know when the configuration value got written),
> > while properties are synchronous (you know). This latter point is really
> > a showstopper for me.
> Oh, and finally you will probably need to devise a way to tell the
> property abstraction which transport it should use. Make sure you have a
> transport that does not allow missing updates (you definitely don't want
> to miss a configuration update).
>
> On the upside of operations: the component designer can choose to reject
> updates if the new value is inconsistent *and* report it to the tooling
> (more changes would be needed if you were to use ports).
>
Check properties input
On 10/17/2011 11:55 AM, gianni borghesan wrote:
> In conclusion (I guess...), the neat way to change a
> "dynamical-adjustable property" is to use an operation (OwnThread) to
> set it, after check.
> What about having its value shown on the component interface (i.e. to
> see its value with an ls), but of course without having the possibility
> of write it?
> or I have to write another operation that just returns the value?
I would say that, in conclusion, there are two or three ways to do it
and that there is no consensus as to what is the best ;-) You just
summarized mine.
In the long run, in my implementation, the operation is used to update
the property so an "ls" will show the updated value. Obviously, this
works only if the coordinator is the only one updating and reading
properties (in you case, the task browser, in my case, ruby scripts or
system management engine), so that the reading / writing is done
sequentially.
Sylvain
Check properties input
On Oct 14, 2011, at 15:09 , Markus Klotzbuecher wrote:
> On Fri, Oct 14, 2011 at 05:37:41PM +0200, Sylvain Joyeux wrote:
>> On 10/14/2011 04:38 PM, Markus Klotzbuecher wrote:
>>> On Fri, Oct 14, 2011 at 04:23:19PM +0200, Sylvain Joyeux wrote:
>>>>> Or just use a Port! If you add it as an EventPort it you will also get
>>>>> notified via updateHook...
>>>> Which is then not a property. Property == configuration, Ports == dataflow.
>>> Property=static configuration, Ports=dataflow and dynamic
>>> configuration. Users too often misuse Properties for dynamic stuff
>>> because it somehow seems more appropriate for configuration than a
>>> port.
>>
>>>> (For the record: I'm discouraging dynamically changing properties, but
>>>> some people unfortunately do want that ...)
>>> You can't discourage dynamically changing properties, they are an
>>> inherent charateristic of a component. You can only discourage calling
>>> them "Properties".
>> I can't disagree more
>>
>> I personally find that having a "Configuration" interface which is
>> different from the "Dataflow" (== Communication ?) interface is a good
>> thing. Having people send configuration parameters through data ports
>> breaks that assumption, which makes tooling on top of it very hard.
>
> I'm fine with a having a (static) configuration interface using
> Properties. But for anything that is supposed to change at runtime,
> the border between DataFlow and Configuration is blurred. In that case
> I prefer using a Port instead of having to manually do locking etc as
> with a method. I also don't see why using a Port should complicate
> tooling?
Use a property to configure the initial value. Put the value on a port. Use the port to allow dynamic reconfiguration on the fly. On cleanup set the property from the port value, and have the property saved to desk for next run.
This has been discussed before on the ML, and is the concept of a "persistent port" (that I believed Hermann named it).
It seems like it might fit this situation ...
S
Check properties input
On Fri, 14 Oct 2011, Sylvain Joyeux wrote:
>
>> Or just use a Port! If you add it as an EventPort it you will also get
>> notified via updateHook...
> Which is then not a property. Property == configuration, Ports == dataflow.
>
> (For the record: I'm discouraging dynamically changing properties, but
> some people unfortunately do want that ...)
I fully agree with Sylvain's remark. A property should, indeed, never
change at runtime, but only when the component is in its (re)configuration
lifecycle state... If it has to change at runtim, it is part of the
component's "runtime behaviour inputs", hence one should use a data port.
> Sylvain
Herman
Check properties input
On 10/14/2011 04:35 PM, Herman Bruyninckx wrote:
> On Fri, 14 Oct 2011, Sylvain Joyeux wrote:
>
>>
>>> Or just use a Port! If you add it as an EventPort it you will also get
>>> notified via updateHook...
>> Which is then not a property. Property == configuration, Ports ==
>> dataflow.
>>
>> (For the record: I'm discouraging dynamically changing properties, but
>> some people unfortunately do want that ...)
>
> I fully agree with Sylvain's remark. A property should, indeed, never
> change at runtime, but only when the component is in its
> (re)configuration
> lifecycle state... If it has to change at runtim, it is part of the
> component's "runtime behaviour inputs", hence one should use a data port.
... and you start having two objects to do the same thing: properties
that are changed dynamically must also be set before configuration time,
which leads to either having to rely on having a sample reaching a
component through a data connection before configureHook is called
(horrible), or having *both* a property and a data port for the same
thing (also horrible).
I personally don't see the problem (theoretical and practical) with
using operations to handle change of configuration at runtime.
Check properties input
On Fri, 14 Oct 2011, Sylvain Joyeux wrote:
> On 10/14/2011 04:35 PM, Herman Bruyninckx wrote:
>> On Fri, 14 Oct 2011, Sylvain Joyeux wrote:
>>
>>>
>>>> Or just use a Port! If you add it as an EventPort it you will also get
>>>> notified via updateHook...
>>> Which is then not a property. Property == configuration, Ports ==
>>> dataflow.
>>>
>>> (For the record: I'm discouraging dynamically changing properties, but
>>> some people unfortunately do want that ...)
>>
>> I fully agree with Sylvain's remark. A property should, indeed, never
>> change at runtime, but only when the component is in its
>> (re)configuration
>> lifecycle state... If it has to change at runtim, it is part of the
>> component's "runtime behaviour inputs", hence one should use a data port.
> ... and you start having two objects to do the same thing: properties
> that are changed dynamically must also be set before configuration time,
> which leads to either having to rely on having a sample reaching a
> component through a data connection before configureHook is called
> (horrible), or having *both* a property and a data port for the same
> thing (also horrible).
>
> I personally don't see the problem (theoretical and practical) with
> using operations to handle change of configuration at runtime.
Fine for you... but I can only wish you good luck with non-atomicity of
your runtime reconfigurations...
Check properties input
On 10/15/2011 02:41 PM, Herman Bruyninckx wrote:
>> that are changed dynamically must also be set before configuration time,
>> which leads to either having to rely on having a sample reaching a
>> component through a data connection before configureHook is called
>> (horrible), or having *both* a property and a data port for the same
>> thing (also horrible).
>>
>> I personally don't see the problem (theoretical and practical) with
>> using operations to handle change of configuration at runtime.
> ... and you start having two objects to do the same thing: properties
>
> Fine for you... but I can only wish you good luck with non-atomicity of
> your runtime reconfigurations...
Except if you have the policy that a consistent set of configuration
parameters should be put in a single struct (a policy we follow).
Therefore, writing a property *is* an atomic reconfiguration.
Obviously, as I stated, I personally believe that dynamic
reconfiguration should be the exception. I have experienced some places
where it was useful, so I cannot rule it out completely.
Sylvain
Check properties input
On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
> On 10/15/2011 02:41 PM, Herman Bruyninckx wrote:
>>> that are changed dynamically must also be set before configuration time,
>>> which leads to either having to rely on having a sample reaching a
>>> component through a data connection before configureHook is called
>>> (horrible), or having *both* a property and a data port for the same
>>> thing (also horrible).
>>>
>>> I personally don't see the problem (theoretical and practical) with
>>> using operations to handle change of configuration at runtime.
>> ... and you start having two objects to do the same thing: properties
>>
>> Fine for you... but I can only wish you good luck with non-atomicity of
>> your runtime reconfigurations...
> Except if you have the policy that a consistent set of configuration
> parameters should be put in a single struct (a policy we follow).
> Therefore, writing a property *is* an atomic reconfiguration.
This approach is good, at first sight, but:
- it does not generalize, because composite components typically require
several (re)configuration actions;
- you rely on the _discipline_ of a developer, while my suggestion can be
hard-checked in a toolchain because it only depends on "Connection" and
not on what is going on inside the Connection.
> Obviously, as I stated, I personally believe that dynamic
> reconfiguration should be the exception. I have experienced some places
> where it was useful, so I cannot rule it out completely.
I think it can... "Dynamic" can have many meanings, though.
> Sylvain
Herman
Check properties input
On 10/17/2011 11:50 AM, Herman Bruyninckx wrote:
> On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
>
>> On 10/15/2011 02:41 PM, Herman Bruyninckx wrote:
>>>> that are changed dynamically must also be set before configuration
>>>> time,
>>>> which leads to either having to rely on having a sample reaching a
>>>> component through a data connection before configureHook is called
>>>> (horrible), or having *both* a property and a data port for the same
>>>> thing (also horrible).
>>>>
>>>> I personally don't see the problem (theoretical and practical) with
>>>> using operations to handle change of configuration at runtime.
>>> ... and you start having two objects to do the same thing: properties
>>>
>>> Fine for you... but I can only wish you good luck with non-atomicity of
>>> your runtime reconfigurations...
>> Except if you have the policy that a consistent set of configuration
>> parameters should be put in a single struct (a policy we follow).
>> Therefore, writing a property *is* an atomic reconfiguration.
>
> This approach is good, at first sight, but:
> - it does not generalize, because composite components typically require
> several (re)configuration actions
So what ? Each component will need to be reconfigured separately at some
point. It is the job of the tooling to make sure that the sequencing is
right. Which it can do if using operations and cannot do if using ports.
And *if* a composite functionality *does* need very constraining
reconfiguration sequence *then* the tooling is free to stop the
components, reconfigure and start them. Having a dynamic interface does
not force you to use it.
> - you rely on the _discipline_ of a developer, while my suggestion can be
> hard-checked in a toolchain because it only depends on "Connection" and
> not on what is going on inside the Connection.
I don't understand what you mean by that.
Check properties input
On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
> On 10/17/2011 11:50 AM, Herman Bruyninckx wrote:
>> On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
>>
>>> On 10/15/2011 02:41 PM, Herman Bruyninckx wrote:
>>>>> that are changed dynamically must also be set before configuration
>>>>> time,
>>>>> which leads to either having to rely on having a sample reaching a
>>>>> component through a data connection before configureHook is called
>>>>> (horrible), or having *both* a property and a data port for the same
>>>>> thing (also horrible).
>>>>>
>>>>> I personally don't see the problem (theoretical and practical) with
>>>>> using operations to handle change of configuration at runtime.
>>>> ... and you start having two objects to do the same thing: properties
>>>>
>>>> Fine for you... but I can only wish you good luck with non-atomicity of
>>>> your runtime reconfigurations...
>>> Except if you have the policy that a consistent set of configuration
>>> parameters should be put in a single struct (a policy we follow).
>>> Therefore, writing a property *is* an atomic reconfiguration.
>>
>> This approach is good, at first sight, but:
>> - it does not generalize, because composite components typically require
>> several (re)configuration actions
> So what ? Each component will need to be reconfigured separately at some
> point. It is the job of the tooling to make sure that the sequencing is
> right. Which it can do if using operations and cannot do if using ports.
Absolutely! That's why I am _fundamentally_ opposed against using ports for
Configuration :-)
> And *if* a composite functionality *does* need very constraining
> reconfiguration sequence *then* the tooling is free to stop the
> components, reconfigure and start them. Having a dynamic interface does
> not force you to use it.
No. but making "features" available too often _invites_ developers to use
them, and, unfortunately, seldom for the use cases those features have been
developed for...
>> - you rely on the _discipline_ of a developer, while my suggestion can be
>> hard-checked in a toolchain because it only depends on "Connection" and
>> not on what is going on inside the Connection.
> I don't understand what you mean by that.
What is causing the confusion exactly?
> Sylvain Joyeux
Herman
> Space& Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
>
--
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
<http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
EURON Coordinator (European Robotics Research Network) <http://www.euron.org>
Open Realtime Control Services <http://www.orocos.org>
Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org>
Check properties input
On 10/17/2011 01:13 PM, Herman Bruyninckx wrote:
> On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
>
>> On 10/17/2011 11:50 AM, Herman Bruyninckx wrote:
>>> On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
>>>
>>>> On 10/15/2011 02:41 PM, Herman Bruyninckx wrote:
>>>>>> that are changed dynamically must also be set before configuration
>>>>>> time,
>>>>>> which leads to either having to rely on having a sample reaching a
>>>>>> component through a data connection before configureHook is called
>>>>>> (horrible), or having *both* a property and a data port for the same
>>>>>> thing (also horrible).
>>>>>>
>>>>>> I personally don't see the problem (theoretical and practical) with
>>>>>> using operations to handle change of configuration at runtime.
>>>>> ... and you start having two objects to do the same thing: properties
>>>>>
>>>>> Fine for you... but I can only wish you good luck with
>>>>> non-atomicity of
>>>>> your runtime reconfigurations...
>>>> Except if you have the policy that a consistent set of configuration
>>>> parameters should be put in a single struct (a policy we follow).
>>>> Therefore, writing a property *is* an atomic reconfiguration.
>>>
>>> This approach is good, at first sight, but:
>>> - it does not generalize, because composite components typically
>>> require
>>> several (re)configuration actions
>> So what ? Each component will need to be reconfigured separately at some
>> point. It is the job of the tooling to make sure that the sequencing is
>> right. Which it can do if using operations and cannot do if using ports.
>
> Absolutely! That's why I am _fundamentally_ opposed against using
> ports for
> Configuration :-)
>
>> And *if* a composite functionality *does* need very constraining
>> reconfiguration sequence *then* the tooling is free to stop the
>> components, reconfigure and start them. Having a dynamic interface does
>> not force you to use it.
>
> No. but making "features" available too often _invites_ developers to use
> them, and, unfortunately, seldom for the use cases those features have
> been
> developed for...
Unfortunately, people *did* start to update properties dynamically even
though the feature was not there. Hence adding the feature so that the
tooling can know about it and double-check its usage.
>>> - you rely on the _discipline_ of a developer, while my suggestion
>>> can be
>>> hard-checked in a toolchain because it only depends on
>>> "Connection" and
>>> not on what is going on inside the Connection.
>> I don't understand what you mean by that.
>
> What is causing the confusion exactly?
I really don't understand it at all. Could you expand it a bit, maybe ?
Sylvain
Check properties input
On Mon, 17 Oct 2011, Sylvain Joyeux wrote:
[...]
>>>> - you rely on the _discipline_ of a developer, while my suggestion
>>>> can be
>>>> hard-checked in a toolchain because it only depends on
>>>> "Connection" and
>>>> not on what is going on inside the Connection.
>>> I don't understand what you mean by that.
>>
>> What is causing the confusion exactly?
> I really don't understand it at all. Could you expand it a bit, maybe ?
What I meant is the following: as soon as RTT will be "compatible" with the
BRICS Component Model, we will have several "types" of components:
Computation, Coordination, Configuration and Communication. It then also
becomes possible to guide the developers in using "best practice"
architectures, more in particular, to stimulate them (or even force
them...) to make a system in which Configuration can only be done via a
synchronous Communication (hence, facilitating atomicity). This "forcing"
then just relies on the facts that (i) every
Computation/Coordination/Communication component _has_ a Configuration
component, and (ii) the Connection between the Configuration component and
the component it is configuring can only be deployed in a way that can
guarantee atomicity. (Without having to rely on the fact that it is done
only via composite data structures; which remains a good idea, of course.)
Hope this helps a little bit... It will not help for current versions of
RTT, since those lack the concepts of composite and the BRICS' 5Cs.
Herman