(This is important for all users.)
I have created a wiki page that shows our views on dealing with the
Method/Command problems in RTT 1.x
There are currently two proposals in the running, of which the second
one has many interesting features, but has not yet been discussed on
this list:
http://www.orocos.org/wiki/rtt/rtt-20/executionflow/dissecting-command-a...
>From now on, if you would update this page, please add a short log
message describing your change. Any theological discussions remain on
this list of course.
Happy reading.
Peter
Discussion: how to improve Method/Command in RTT 2.0
On Fri, Oct 30, 2009 at 12:41 PM, Peter Soetens <peter [..] ...>wrote:
> (This is important for all users.)
>
> I have created a wiki page that shows our views on dealing with the
> Method/Command problems in RTT 1.x
>
> There are currently two proposals in the running, of which the second
> one has many interesting features, but has not yet been discussed on
> this list:
>
> http://www.orocos.org/wiki/rtt/rtt-20/executionflow/dissecting-command-a...
>
>
One question, in proposal 2, there are these examples:
New calling:
the_service.call("hello", result); // also allowed:
the_service("hello", result);
New sending:
the_service.send("hello", ignored_result);
New sending with collecting results:
h = the_service.send("hello", ignored_result);
// some time later:
the_service.collect(h, "ignored", result); // blocking !
What is the meaning of the 'ignored_result' argument? is it a variable that
must be provided but in those cases is unused/ignored?
> >From now on, if you would update this page, please add a short log
> message describing your change. Any theological discussions remain on
> this list of course.
>
> Happy reading.
>
> Peter
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Discussion: how to improve Method/Command in RTT 2.0
On Monday 02 November 2009 14:29:47 you wrote:
> > I actually don't agree. The design rule in my project is that if some
> > properties need to be changed together, then create ONE property that is
> > a struct with all the different parameters in it.
>
> That's another option. But then every user/gui/xml parser needs to
> understand all your structs (they will all try to update or read your
> props). The advantage of properties is that the number of types is
> limited. With a more powerful type system, this might be a lesser
> advantage though.
I don't get that. I marshal anything that orogen understands as properties, so
it is completely extendable there ...
Discussion: how to improve Method/Command in RTT 2.0
On Monday 02 November 2009 13:44:38 you wrote:
> > - one feature of commands that I find important, also from a supervision
> > point of view, is the separation between the "computation" part of the
> > command and the "acceptation" part of it. What I am referring to is that
> > the command's user can know if the command failed because the
> > parameters/task state were wrong (a validation method returned false) or
> > during the computation itself.
>
> Such feature was omitted from both proposals, but by collecing the
> results of an asynchronous call, you'd get this information too. So I
> think this is not a problem then ?
Except that instead of having it embedded in the framework, you would require
the component developer to follow a design guideline ... More prone to
problems, the different supervision frameworks would have to agree on a
standard way to report parameter errors, and each of those frameworks would
have to constrain the module developer (i.e. if you want to use commands, you
need to follow those rules). I'd rather have it embedded in the RTT, but YMMV.
> > Related to this proposal, I think it would be interesting to extend the
> > property access by associating a getter and setter "service" with them.
> > It would add a few things:
> > - transports would only have to handle services, properties would
> > follow. - external programs that use the transports would be able to do
> > setting/getting asynchronous if needed.
> > - validation of new property values would be done at the source *and* it
> > would be very easy to trigger only reconfiguration: since a C++ method
> > is called on property change, one can easily implement reconfiguration at
> > runtime, or refuse the property change if the reconfiguration is possible
> > only in the STOPPED/PRE_OPERATIONAL states.
> > - the current C++ API can be retained, calling the services "behind the
> > scene". In the same way
>
> I'm assuming that you mean the service allows something like 'update
> properties with this new property set', and that a user callback
> function validates, and atomically applies the changes ?
>
> That seems the only way to do it correctly. Doing it on a per-property
> basis is not gonna work.
I actually don't agree. The design rule in my project is that if some
properties need to be changed together, then create ONE property that is a
struct with all the different parameters in it.
Discussion: how to improve Method/Command in RTT 2.0
On Mon, Nov 2, 2009 at 14:11, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> On Monday 02 November 2009 13:44:38 you wrote:
>> > - one feature of commands that I find important, also from a supervision
>> > point of view, is the separation between the "computation" part of the
>> > command and the "acceptation" part of it. What I am referring to is that
>> > the command's user can know if the command failed because the
>> > parameters/task state were wrong (a validation method returned false) or
>> > during the computation itself.
>>
>> Such feature was omitted from both proposals, but by collecing the
>> results of an asynchronous call, you'd get this information too. So I
>> think this is not a problem then ?
> Except that instead of having it embedded in the framework, you would require
> the component developer to follow a design guideline ... More prone to
> problems, the different supervision frameworks would have to agree on a
> standard way to report parameter errors, and each of those frameworks would
> have to constrain the module developer (i.e. if you want to use commands, you
> need to follow those rules). I'd rather have it embedded in the RTT, but YMMV.
Feel free to add a short proposal that demonstrates your use case.
>
>> > Related to this proposal, I think it would be interesting to extend the
>> > property access by associating a getter and setter "service" with them.
>> > It would add a few things:
>> > - transports would only have to handle services, properties would
>> > follow. - external programs that use the transports would be able to do
>> > setting/getting asynchronous if needed.
>> > - validation of new property values would be done at the source *and* it
>> > would be very easy to trigger only reconfiguration: since a C++ method
>> > is called on property change, one can easily implement reconfiguration at
>> > runtime, or refuse the property change if the reconfiguration is possible
>> > only in the STOPPED/PRE_OPERATIONAL states.
>> > - the current C++ API can be retained, calling the services "behind the
>> > scene". In the same way
>>
>> I'm assuming that you mean the service allows something like 'update
>> properties with this new property set', and that a user callback
>> function validates, and atomically applies the changes ?
>>
>> That seems the only way to do it correctly. Doing it on a per-property
>> basis is not gonna work.
> I actually don't agree. The design rule in my project is that if some
> properties need to be changed together, then create ONE property that is a
> struct with all the different parameters in it.
That's another option. But then every user/gui/xml parser needs to
understand all your structs (they will all try to update or read your
props). The advantage of properties is that the number of types is
limited. With a more powerful type system, this might be a lesser
advantage though.
Peter