Discussion: how to improve Method/Command in RTT 2.0

(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

Some remarks:
- for me, proposal (1) is a definite no. The send-and-forget principle of
Message would make the component very hard to supervise properly [you don't
know if your actions fail or not], and using a synchronous call is not
possible either, as I don't want a buggy module to influence the whole
supervision.
- 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.

Other things:
- one should be able to poll the services in a non-blocking manner (again,
for supervision). That is *very* important.

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

Discussion: how to improve Method/Command in RTT 2.0

On Mon, Nov 2, 2009 at 12:22, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> Some remarks:
>  - for me, proposal (1) is a definite no. The send-and-forget principle of
>   Message would make the component very hard to supervise properly [you don't
>   know if your actions fail or not], and using a synchronous call is not
>   possible either, as I don't want a buggy module to influence the whole
>   supervision.

Ok.

>  - 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 ?

>
> Other things:
>  - one should be able to poll the services in a non-blocking manner (again,
>   for supervision). That is *very* important.

This is described in the wiki (collect_if_done). The return value
remains an issue with this function. It's probably a function
argument.

>
> 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.

Peter

Discussion: how to improve Method/Command in RTT2.0

> On Mon, Nov 2, 2009 at 12:22, Sylvain Joyeux
> <sylvain [dot] joyeux [..] ...> wrote:
> > Some remarks:
> >  - for me, proposal (1) is a definite no. The
> send-and-forget principle of
> >   Message would make the component very hard to supervise
> properly [you don't
> >   know if your actions fail or not], and using a
> synchronous call is not
> >   possible either, as I don't want a buggy module to
> influence the whole
> >   supervision.
>
> Ok.

Seconded.

>
> >  - 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 ?
>
> >
> > Other things:
> >  - one should be able to poll the services in a
> non-blocking manner (again,
> >   for supervision). That is *very* important.
>
> This is described in the wiki (collect_if_done). The return value
> remains an issue with this function. It's probably a function
> argument.
>

There seems to be three standard responses: 1) done, here are the
results; 2) still working; 3) error. It doesn't seem the third is
covered (?)

- alexis.

Discussion: how to improve Method/Command in RTT2.0

On Mon, Nov 2, 2009 at 17:27, Wieland, Alexis P <Alexis [dot] P [dot] Wieland [..] ...
> wrote:

> > >
> > > Other things:
> > > - one should be able to poll the services in a
> > non-blocking manner (again,
> > > for supervision). That is *very* important.
> >
> > This is described in the wiki (collect_if_done). The return value
> > remains an issue with this function. It's probably a function
> > argument.
> >
>
> There seems to be three standard responses: 1) done, here are the
> results; 2) still working; 3) error. It doesn't seem the third is
> covered (?)
>

Yep, we need to cover all three cases. I think we'll apply the same logic as
we did with Input Ports. There we had 'NoData', 'OldData' and 'NewData' as
answers (FlowStatus enum). We'll have here something like: CollectFailure,
CollectDone, CollectAgain ?

Peter

Discussion: how to improve Method/Command in RTT2.0

On Thursday 05 November 2009 22:03:36 you wrote:
> On Mon, Nov 2, 2009 at 17:27, Wieland, Alexis P
> <Alexis [dot] P [dot] Wieland [..] ...
>
> > wrote:
> > > > Other things:
> > > > - one should be able to poll the services in a
> > >
> > > non-blocking manner (again,
> > >
> > > > for supervision). That is *very* important.
> > >
> > > This is described in the wiki (collect_if_done). The return value
> > > remains an issue with this function. It's probably a function
> > > argument.
> >
> > There seems to be three standard responses: 1) done, here are the
> > results; 2) still working; 3) error. It doesn't seem the third is
> > covered (?)
>
> Yep, we need to cover all three cases. I think we'll apply the same logic
> as we did with Input Ports. There we had 'NoData', 'OldData' and 'NewData'
> as answers (FlowStatus enum). We'll have here something like:
> CollectFailure, CollectDone, CollectAgain ?

Mmmm ... I find CollectFailure and CollectDone confusing, as the *call* failed
or is done, not the collection (right ?).

what about: CallFailure, CallDone, CallRunning ?

Discussion: how to improve Method/Command in RTT2.0

On Fri, Nov 6, 2009 at 15:07, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:

> On Thursday 05 November 2009 22:03:36 you wrote:
> > On Mon, Nov 2, 2009 at 17:27, Wieland, Alexis P
> > <Alexis [dot] P [dot] Wieland [..] ...
> >
> > > wrote:
> > > > > Other things:
> > > > > - one should be able to poll the services in a
> > > >
> > > > non-blocking manner (again,
> > > >
> > > > > for supervision). That is *very* important.
> > > >
> > > > This is described in the wiki (collect_if_done). The return value
> > > > remains an issue with this function. It's probably a function
> > > > argument.
> > >
> > > There seems to be three standard responses: 1) done, here are the
> > > results; 2) still working; 3) error. It doesn't seem the third is
> > > covered (?)
> >
> > Yep, we need to cover all three cases. I think we'll apply the same logic
> > as we did with Input Ports. There we had 'NoData', 'OldData' and
> 'NewData'
> > as answers (FlowStatus enum). We'll have here something like:
> > CollectFailure, CollectDone, CollectAgain ?
>
> Mmmm ... I find CollectFailure and CollectDone confusing, as the *call*
> failed
> or is done, not the collection (right ?).
>
> what about: CallFailure, CallDone, CallRunning ?
>

Makes more sense... We still didn't decide on the naming of 'call'
(blocking) and 'send' (non-blocking + collect). Ideas ?

Peter

Discussion: how to improve Method/Command in RTT 2.0

Hi Peter,

On Fri, Oct 30, 2009 at 12:41:39PM +0100, Peter Soetens 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...
>
> >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.

Thanks for the nice writeup. I favor proposal 2. Some remarks:

"Dissecting the cases":

- it occured to me that "X" in the table is sort of a deferred work
mechanism: "run this in my thread, but later". It's sending a
command to yourself, i.e. a "RTT bottom half". I could construct a
use case :-) but if nobody missed it we shouldn't include it.

- There is one more dimension: are Methods called serialized or not,
ie does the implementation use locking? Today it's up to the user,
coulnd't a "SERIALIZE" flag be part of the Method creation API?

"Proposal 2: Method/Service"

- I like send and call much more than message etc. ! Maybe "request"
is better than "send"?

- Can I define Services that can be both "call'ed" and "sent-to"?

- Will it be possible to query a service about how it can be called?

- Do you think the handle and collect mechanism can be implemented
reasonably without humongous amounts of unreadable code ;-) ?

- I don't like "engines" showing up in the user API!

Markus

Discussion: how to improve Method/Command in RTT 2.0

On Oct 30, 2009, at 07:41 , Peter Soetens 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...
>
>> 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

It looks like both proposal's are dropping explicit implementation of
the completion condition, but are otherwise providing the 3 current
purposes of Command's? (subject to the following question)

Is it true that Proposal 1's Message, and Proposal 2's send(), both
provide for the first two purposes of today's Commands: thread-safe
execution of a piece of code in a component, and execution within same
component?

Proposal 2 appears to prevent the component choosing how it responds
to a request. Either immediately (like an existing Method call, but
not thread-safe within the component), or when it is thread-safe (ala
existing Command). It appears that the caller gets to make that choice?

Proposal 2 looks to have better long-term capabilities, but at the
expense of more work now for the developers?

Also, it looks to me that Proposal 1 is an evolutionary change to the
existing difficult-to-use (but very useful!) Commands, which could be
a step towards Proposal 2 as a longer term goal of services within
Orocos?

Cheers
Stephen

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?

> >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

2009/10/30 Adolfo Rodríguez Tsouroukdissian <dofo79 [..] ...>:
>
>
> 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?

Indeed. The signature of the service is fixed. Any 'out' argument
(like a int&) will need to be provided, but will be ignored during the
send. In the same manner, during the collection phase, the 'in'
arguments (like int, const int&,...) are ignored. In practice, you can
just provide twice the same arguments:

  string hello = "hello";
  int result = 0;
  h = the_service.send( hello, result); // (1)
 
  // some time later:
  the_service.collect(h, hello, result); // (2)

In (1), the result will be left untouched. In (2) the hello will not be read.

Peter

Discussion: how to improve Method/Command in RTT 2.0

Hi Peter,

On Fri, Oct 30, 2009 at 12:41:39PM +0100, Peter Soetens 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...
>
> >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.

Thanks for the nice writeup. I favor proposal 2. Some remarks:

"Dissecting the cases":

- it occured to me that "X" in the table is sort of a deferred work
mechanism: "run this in my thread, but later". It's sending a
command to yourself, i.e. a "RTT bottom half". I could construct a
use case :-) but if nobody missed it we shouldn't include it.

- There is one more dimension: are Methods called serialized or not,
ie does the implementation use locking? Today it's up to the user,
coulnd't a "SERIALIZE" flag be part of the Method creation API?

"Proposal 2: Method/Service"

- I like send and call much more than message etc. ! Maybe "request"
is better than "send"?

- Can I define Services that can be both "call'ed" and "sent-to"?

- Will it be possible to query a service about how it can be called?

- Do you think the handle and collect mechanism can be implemented
reasonably without humongous amounts of unreadable code ;-) ?

- I don't like "engines" showing up in the user API!

Markus

Discussion: how to improve Method/Command in RTT 2.0

On Sat, Oct 31, 2009 at 09:15, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> Hi Peter,
>
> On Fri, Oct 30, 2009 at 12:41:39PM +0100, Peter Soetens 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...
>>
>> >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.
>
> Thanks for the nice writeup. I favor proposal 2. Some remarks:
>
> "Dissecting the cases":
>
>  - it occured to me that "X" in the table is sort of a deferred work
>    mechanism: "run this in my thread, but later". It's sending a
>    command to yourself, i.e. a "RTT bottom half". I could construct a
>    use case :-) but if nobody missed it we shouldn't include it.

I don't follow here. From the caller's viewpoint, the only reason I
can think of to send an asynchronous method invocation is because of
resource constraints. So I don't see the advantage of doing it anyway
in your own thread at a later point in time. But it could be a
property on the caller side that says that this is an allowed solution
to the problem.

>
>  - There is one more dimension: are Methods called serialized or not,
>    ie does the implementation use locking? Today it's up to the user,
>    coulnd't a "SERIALIZE" flag be part of the Method creation API?

Yes you could add that.

>
> "Proposal 2: Method/Service"
>
>  - I like send and call much more than message etc. ! Maybe "request"
>    is better than "send"?

Maybe. In other literature it is sometimes refered to as 'AMI',
Asynchronous Method Invocation.

>
>  - Can I define Services that can be both "call'ed" and "sent-to"?

Each service is de facto available for both modes. The caller doesn't
know how the service is implemented, it is orthogonal.

>
>  - Will it be possible to query a service about how it can be called?

The answer will always be 'both'. ICE has implemented this too like
this. Any method can be made called synchronously and asynchronously.

>
>  - Do you think the handle and collect mechanism can be implemented
>    reasonably without humongous amounts of unreadable code ;-) ?

Not a chance ! Well, due to templates, we *do* know if a parameter is
an in or an out. So I don't think its that hard to code. I'm relying
on my experience here.

>
>  - I don't like "engines" showing up in the user API!

Yep, that's an issue, but we need to provide a pointer to the
component that will execute the function. We could also require a
TaskCore pointer instead of engine.

I updated the wiki a bit more to answer some of these questions. I'm
also wondering if I shouldn't rename 'Service' -> 'Operation' and call
a collection of operations in an interface a 'Service'. This would
line up better with OSGi naming. Where Service maps to Interface.

Peter

Discussion: how to improve Method/Command in RTT 2.0

On Sat, Oct 31, 2009 at 09:15, Markus Klotzbuecher
<markus [dot] klotzbuecher [..] ...> wrote:
> Hi Peter,
>
> On Fri, Oct 30, 2009 at 12:41:39PM +0100, Peter Soetens 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...
>>
>> >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.
>
> Thanks for the nice writeup. I favor proposal 2. Some remarks:
>
> "Dissecting the cases":
>
>  - it occured to me that "X" in the table is sort of a deferred work
>    mechanism: "run this in my thread, but later". It's sending a
>    command to yourself, i.e. a "RTT bottom half". I could construct a
>    use case :-) but if nobody missed it we shouldn't include it.

I don't follow here. From the caller's viewpoint, the only reason I
can think of to send an asynchronous method invocation is because of
resource constraints. So I don't see the advantage of doing it anyway
in your own thread at a later point in time. But it could be a
property on the caller side that says that this is an allowed solution
to the problem.

>
>  - There is one more dimension: are Methods called serialized or not,
>    ie does the implementation use locking? Today it's up to the user,
>    coulnd't a "SERIALIZE" flag be part of the Method creation API?

Yes you could add that.

>
> "Proposal 2: Method/Service"
>
>  - I like send and call much more than message etc. ! Maybe "request"
>    is better than "send"?

Maybe. In other literature it is sometimes refered to as 'AMI',
Asynchronous Method Invocation.

>
>  - Can I define Services that can be both "call'ed" and "sent-to"?

Each service is de facto available for both modes. The caller doesn't
know how the service is implemented, it is orthogonal.

>
>  - Will it be possible to query a service about how it can be called?

The answer will always be 'both'. ICE has implemented this too like
this. Any method can be made called synchronously and asynchronously.

>
>  - Do you think the handle and collect mechanism can be implemented
>    reasonably without humongous amounts of unreadable code ;-) ?

Not a chance ! Well, due to templates, we *do* know if a parameter is
an in or an out. So I don't think its that hard to code. I'm relying
on my experience here.

>
>  - I don't like "engines" showing up in the user API!

Yep, that's an issue, but we need to provide a pointer to the
component that will execute the function. We could also require a
TaskCore pointer instead of engine.

I updated the wiki a bit more to answer some of these questions. I'm
also wondering if I shouldn't rename 'Service' -> 'Operation' and call
a collection of operations in an interface a 'Service'. This would
line up better with OSGi naming. Where Service maps to Interface.

Peter

Discussion: how to improve Method/Command in RTT 2.0

On Sat, Oct 31, 2009 at 03:55:09PM +0100, Peter Soetens wrote:
> On Sat, Oct 31, 2009 at 09:15, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > Hi Peter,
> >
> > On Fri, Oct 30, 2009 at 12:41:39PM +0100, Peter Soetens 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...
> >>
> >> >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.
> >
> > Thanks for the nice writeup. I favor proposal 2. Some remarks:
> >
> > "Dissecting the cases":
> >
> >  - it occured to me that "X" in the table is sort of a deferred work
> >    mechanism: "run this in my thread, but later". It's sending a
> >    command to yourself, i.e. a "RTT bottom half". I could construct a
> >    use case :-) but if nobody missed it we shouldn't include it.
>
> I don't follow here. From the caller's viewpoint, the only reason I
> can think of to send an asynchronous method invocation is because of
> resource constraints. So I don't see the advantage of doing it anyway
> in your own thread at a later point in time. But it could be a
> property on the caller side that says that this is an allowed solution
> to the problem.

Yeah, it doesn't make much sense.

> >  - There is one more dimension: are Methods called serialized or not,
> >    ie does the implementation use locking? Today it's up to the user,
> >    coulnd't a "SERIALIZE" flag be part of the Method creation API?
>
> Yes you could add that.
>
> >
> > "Proposal 2: Method/Service"
> >
> >  - I like send and call much more than message etc. ! Maybe "request"
> >    is better than "send"?
>
> Maybe. In other literature it is sometimes refered to as 'AMI',
> Asynchronous Method Invocation.

Then I'd prefer call.

> >
> >  - Can I define Services that can be both "call'ed" and "sent-to"?
>
> Each service is de facto available for both modes. The caller doesn't
> know how the service is implemented, it is orthogonal.

Ok.

> >  - Will it be possible to query a service about how it can be called?
>
> The answer will always be 'both'. ICE has implemented this too like
> this. Any method can be made called synchronously and asynchronously.

Ok! I think this is good.

> >  - Do you think the handle and collect mechanism can be implemented
> >    reasonably without humongous amounts of unreadable code ;-) ?
>
> Not a chance ! Well, due to templates, we *do* know if a parameter is
> an in or an out. So I don't think its that hard to code. I'm relying
> on my experience here.

Fine.

> >  - I don't like "engines" showing up in the user API!
>
> Yep, that's an issue, but we need to provide a pointer to the
> component that will execute the function. We could also require a
> TaskCore pointer instead of engine.

Ok.

> I updated the wiki a bit more to answer some of these questions. I'm
> also wondering if I shouldn't rename 'Service' -> 'Operation' and call
> a collection of operations in an interface a 'Service'. This would
> line up better with OSGi naming. Where Service maps to Interface.

Fine for me.

Best regards
Markus

Discussion: how to improve Method/Command in RTT 2.0

On Sat, Oct 31, 2009 at 03:55:09PM +0100, Peter Soetens wrote:
> On Sat, Oct 31, 2009 at 09:15, Markus Klotzbuecher
> <markus [dot] klotzbuecher [..] ...> wrote:
> > Hi Peter,
> >
> > On Fri, Oct 30, 2009 at 12:41:39PM +0100, Peter Soetens 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...
> >>
> >> >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.
> >
> > Thanks for the nice writeup. I favor proposal 2. Some remarks:
> >
> > "Dissecting the cases":
> >
> >  - it occured to me that "X" in the table is sort of a deferred work
> >    mechanism: "run this in my thread, but later". It's sending a
> >    command to yourself, i.e. a "RTT bottom half". I could construct a
> >    use case :-) but if nobody missed it we shouldn't include it.
>
> I don't follow here. From the caller's viewpoint, the only reason I
> can think of to send an asynchronous method invocation is because of
> resource constraints. So I don't see the advantage of doing it anyway
> in your own thread at a later point in time. But it could be a
> property on the caller side that says that this is an allowed solution
> to the problem.

Yeah, it doesn't make much sense.

> >  - There is one more dimension: are Methods called serialized or not,
> >    ie does the implementation use locking? Today it's up to the user,
> >    coulnd't a "SERIALIZE" flag be part of the Method creation API?
>
> Yes you could add that.
>
> >
> > "Proposal 2: Method/Service"
> >
> >  - I like send and call much more than message etc. ! Maybe "request"
> >    is better than "send"?
>
> Maybe. In other literature it is sometimes refered to as 'AMI',
> Asynchronous Method Invocation.

Then I'd prefer call.

> >
> >  - Can I define Services that can be both "call'ed" and "sent-to"?
>
> Each service is de facto available for both modes. The caller doesn't
> know how the service is implemented, it is orthogonal.

Ok.

> >  - Will it be possible to query a service about how it can be called?
>
> The answer will always be 'both'. ICE has implemented this too like
> this. Any method can be made called synchronously and asynchronously.

Ok! I think this is good.

> >  - Do you think the handle and collect mechanism can be implemented
> >    reasonably without humongous amounts of unreadable code ;-) ?
>
> Not a chance ! Well, due to templates, we *do* know if a parameter is
> an in or an out. So I don't think its that hard to code. I'm relying
> on my experience here.

Fine.

> >  - I don't like "engines" showing up in the user API!
>
> Yep, that's an issue, but we need to provide a pointer to the
> component that will execute the function. We could also require a
> TaskCore pointer instead of engine.

Ok.

> I updated the wiki a bit more to answer some of these questions. I'm
> also wondering if I shouldn't rename 'Service' -> 'Operation' and call
> a collection of operations in an interface a 'Service'. This would
> line up better with OSGi naming. Where Service maps to Interface.

Fine for me.

Best regards
Markus

Discussion: how to improve Method/Command in RTT 2.0

On Oct 30, 2009, at 07:41 , Peter Soetens 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...
>
>> 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

It looks like both proposal's are dropping explicit implementation of
the completion condition, but are otherwise providing the 3 current
purposes of Command's? (subject to the following question)

Is it true that Proposal 1's Message, and Proposal 2's send(), both
provide for the first two purposes of today's Commands: thread-safe
execution of a piece of code in a component, and execution within same
component?

Proposal 2 appears to prevent the component choosing how it responds
to a request. Either immediately (like an existing Method call, but
not thread-safe within the component), or when it is thread-safe (ala
existing Command). It appears that the caller gets to make that choice?

Proposal 2 looks to have better long-term capabilities, but at the
expense of more work now for the developers?

Also, it looks to me that Proposal 1 is an evolutionary change to the
existing difficult-to-use (but very useful!) Commands, which could be
a step towards Proposal 2 as a longer term goal of services within
Orocos?

Cheers
Stephen

Discussion: how to improve Method/Command in RTT 2.0

On Fri, Oct 30, 2009 at 16:41, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 30, 2009, at 07:41 , Peter Soetens 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...
>>
>>> 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
>
> It looks like both proposal's are dropping explicit implementation of the
> completion condition, but are otherwise providing the 3 current purposes of
> Command's? (subject to the following question)

Yes.

>
> Is it true that Proposal 1's Message, and Proposal 2's send(), both provide
> for the first two purposes of today's Commands: thread-safe execution of a
> piece of code in a component, and execution within same component?

Yes.

>
>
> Proposal 2 appears to prevent the component choosing how it responds to a
> request. Either immediately (like an existing Method call, but not
> thread-safe within the component), or when it is thread-safe (ala existing
> Command). It appears that the caller gets to make that choice?

No. I should have shown the component side too. Component side in proposal 1
is very similar to today's state. Component side in proposal 2 is 'new':

RTT::Service the_service( &foo_service ); // by default creates a
service executed by caller, equivalent to Method
the_service.setExecutor( this->engine() ); // sets the service to be
executed by engine(), ie the component's thread, equivalent to Command
//above in one line:
RTT::Service the_service( &foo_service, this->engine() );

>
> Proposal 2 looks to have better long-term capabilities, but at the expense
> of more work now for the developers?

Yes, although semantically, Proposal 2 can express what Proposal 1
provides, the renaming is just harder to automate. I see no
adaptations in application design. We can map both command and method
unambiguously (except for the completion condition).

>
> Also, it looks to me that Proposal 1 is an evolutionary change to the
> existing difficult-to-use (but very useful!) Commands, which could be a step
> towards Proposal 2 as a longer term goal of services within Orocos?

2 is just more flexible than 1. It doesn't fix the caller into 'you
must know that foo_service is a command if you want to use it'. There
are just a bunch of services and you can invoke them however you want.
2 Is simpler for the user to use and understand. I'm getting more and
more convinced that fixing the caller to the execution semantics of
the 'receiver' is a bad form of exposing implementation. It's too
coupled. Proposal 2 decouples these and allows for more re-use.

Peter

Discussion: how to improve Method/Command in RTT 2.0

On Fri, Oct 30, 2009 at 16:41, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Oct 30, 2009, at 07:41 , Peter Soetens 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...
>>
>>> 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
>
> It looks like both proposal's are dropping explicit implementation of the
> completion condition, but are otherwise providing the 3 current purposes of
> Command's? (subject to the following question)

Yes.

>
> Is it true that Proposal 1's Message, and Proposal 2's send(), both provide
> for the first two purposes of today's Commands: thread-safe execution of a
> piece of code in a component, and execution within same component?

Yes.

>
>
> Proposal 2 appears to prevent the component choosing how it responds to a
> request. Either immediately (like an existing Method call, but not
> thread-safe within the component), or when it is thread-safe (ala existing
> Command). It appears that the caller gets to make that choice?

No. I should have shown the component side too. Component side in proposal 1
is very similar to today's state. Component side in proposal 2 is 'new':

RTT::Service the_service( &foo_service ); // by default creates a
service executed by caller, equivalent to Method
the_service.setExecutor( this->engine() ); // sets the service to be
executed by engine(), ie the component's thread, equivalent to Command
//above in one line:
RTT::Service the_service( &foo_service, this->engine() );

>
> Proposal 2 looks to have better long-term capabilities, but at the expense
> of more work now for the developers?

Yes, although semantically, Proposal 2 can express what Proposal 1
provides, the renaming is just harder to automate. I see no
adaptations in application design. We can map both command and method
unambiguously (except for the completion condition).

>
> Also, it looks to me that Proposal 1 is an evolutionary change to the
> existing difficult-to-use (but very useful!) Commands, which could be a step
> towards Proposal 2 as a longer term goal of services within Orocos?

2 is just more flexible than 1. It doesn't fix the caller into 'you
must know that foo_service is a command if you want to use it'. There
are just a bunch of services and you can invoke them however you want.
2 Is simpler for the user to use and understand. I'm getting more and
more convinced that fixing the caller to the execution semantics of
the 'receiver' is a bad form of exposing implementation. It's too
coupled. Proposal 2 decouples these and allows for more re-use.

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

2009/10/30 Adolfo Rodríguez Tsouroukdissian <dofo79 [..] ...>:
>
>
> 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?

Indeed. The signature of the service is fixed. Any 'out' argument
(like a int&) will need to be provided, but will be ignored during the
send. In the same manner, during the collection phase, the 'in'
arguments (like int, const int&,...) are ignored. In practice, you can
just provide twice the same arguments:

  string hello = "hello";
  int result = 0;
  h = the_service.send( hello, result); // (1)
 
  // some time later:
  the_service.collect(h, hello, result); // (2)

In (1), the result will be left untouched. In (2) the hello will not be read.

Peter