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

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

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

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

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

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

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