Example code for Proposal 2: Method/Operation/Service

I've done some reshuffling of the wiki and added example code for using the
new interfaces.

http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/ne...

It's clear that the amount of boilerplate code is still pretty huge. I think
we can generate most/all of that, so we might end up with an rtservgen too
in the end. The generator need not to be more intelligent than Doxygen for
reading virtual function definitions in a class. Does orogen read virtual
function definitions ?

There were already such examples for the first Method/Message proposal, see
a level higher on the wiki.

Peter

Example code for Proposal 2: Method/Operation/Service

On Fri, Nov 06, 2009 at 11:59:11AM +0100, Peter Soetens wrote:
> I've done some reshuffling of the wiki and added example code for using the new
> interfaces.
>
> http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/
> new-method-operation-service-api
>
> It's clear that the amount of boilerplate code is still pretty huge. I think we
> can generate most/all of that, so we might end up with an rtservgen too in the
> end. The generator need not to be more intelligent than Doxygen for reading
> virtual function definitions in a class. Does orogen read virtual function
> definitions ?
>
> There were already such examples for the first Method/Message proposal, see a
> level higher on the wiki.

Looks quite good, and much simpler than before!

Some minor questions/remarks:

- WRT the 'calls' and 'doc' methods on operation. It should not be
possible to define a valid method without providing the doc info.

- How will the 'ServiceProvider' and 'requires' classes map to
Interfaces? *Are* they the interface or will Interfaces and Service
Providers both hold a reference to Operations?

- You write:

"Note that both ServiceRequester below and ServiceProvider above have
the same name "MyService". This is how the deployment can link the
interfaces together automatically."

Will that not create the same problems as we have with AutoConnect
and Ports now? Should there not be an explicit and semantic "type"
which defines what can be connected sensibly?

- Is 'Service' a good name? It might cause confusion down the road if
you plan to introduce something OSGi like. Or is this actually the
first step in that direction?

Best regards
Markus

Example code for Proposal 2: Method/Operation/Service

On Tue, Nov 10, 2009 at 08:55, Markus Klotzbuecher <
markus [dot] klotzbuecher [..] ...> wrote:

> On Fri, Nov 06, 2009 at 11:59:11AM +0100, Peter Soetens wrote:
> > I've done some reshuffling of the wiki and added example code for using
> the new
> > interfaces.
> >
> > http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/
> > new-method-operation-service-api
> >
> > It's clear that the amount of boilerplate code is still pretty huge. I
> think we
> > can generate most/all of that, so we might end up with an rtservgen too
> in the
> > end. The generator need not to be more intelligent than Doxygen for
> reading
> > virtual function definitions in a class. Does orogen read virtual
> function
> > definitions ?
> >
> > There were already such examples for the first Method/Message proposal,
> see a
> > level higher on the wiki.
>
> Looks quite good, and much simpler than before!
>

It will only be simpler if there's tooling in place :-)

>
> Some minor questions/remarks:
>
> - WRT the 'calls' and 'doc' methods on operation. It should not be
> possible to define a valid method without providing the doc info.
>

Separating documentation was actually my go at making it optional :-) The
only thing we really require is the name. In 1.x, omitting the docs meant it
was not a scripting method. Bad. I want to separate the scripting/non
scripting (for embedded) registrations by using a different method name for
that. doc becomes optional to allow rapid prototyping. I've seen to many
"","","",""... If we generate the requesters/providers, the docs can be
pulled from doxygen tags.

>
> - How will the 'ServiceProvider' and 'requires' classes map to
> Interfaces? *Are* they the interface or will Interfaces and Service
> Providers both hold a reference to Operations?
>

They are the Orocos representation of C++ interfaces. I.e. TaskContext ->
C++ object, Service -> C++ interface.

>
> - You write:
>
> "Note that both ServiceRequester below and ServiceProvider above have
> the same name "MyService". This is how the deployment can link the
> interfaces together automatically."
>
> Will that not create the same problems as we have with AutoConnect
> and Ports now? Should there not be an explicit and semantic "type"
> which defines what can be connected sensibly?
>

MyService *is* the type name of the interface. It's like agreeing on the
data type sent over a data port. It better be identical.

The 'automatic' kind is not so auto/proble-matic as with AutoConnect. You'll
still have to say that A connects to B, but from there on, the matching can
happen on service name. We'll leave the option to connect only a single
service from A to B (instead of all possible). I see it more as a syntax
thing in the end, not a fundamental property.

- Is 'Service' a good name? It might cause confusion down the road if
> you plan to introduce something OSGi like. Or is this actually the
> first step in that direction?
>

It is the first step. I saw no reason to name it differently. These objects
will in time be used by the service management code. These services will be
offered, connected, disconnected etc. I thought it was in line with naming
used in other frameworks.

Peter

Example code for Proposal 2: Method/Operation/Service

On Tue, Nov 10, 2009 at 10:00:10AM +0100, Peter Soetens wrote:
> On Tue, Nov 10, 2009 at 08:55, Markus Klotzbuecher <
> markus [dot] klotzbuecher [..] ...> wrote:
>
> On Fri, Nov 06, 2009 at 11:59:11AM +0100, Peter Soetens wrote:
> > I've done some reshuffling of the wiki and added example code for using
> the new
> > interfaces.
> >
> > http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/
> > new-method-operation-service-api
> >
> > It's clear that the amount of boilerplate code is still pretty huge. I
> think we
> > can generate most/all of that, so we might end up with an rtservgen too
> in the
> > end. The generator need not to be more intelligent than Doxygen for
> reading
> > virtual function definitions in a class. Does orogen read virtual
> function
> > definitions ?
> >
> > There were already such examples for the first Method/Message proposal,
> see a
> > level higher on the wiki.
>
> Looks quite good, and much simpler than before!
>
>
> It will only be simpler if there's tooling in place :-)

Hmm.

> Some minor questions/remarks:
>
> - WRT the 'calls' and 'doc' methods on operation. It should not be
> possible to define a valid method without providing the doc info.
>
>
> Separating documentation was actually my go at making it optional :-) The only
> thing we really require is the name. In 1.x, omitting the docs meant it was not

Ouch.

> a scripting method. Bad. I want to separate the scripting/non scripting (for
> embedded) registrations by using a different method name for that. doc becomes

Why that seperation? Isn't 'embedded' a compile time option?

> optional to allow rapid prototyping. I've seen to many "","","",""... If we

That has the advantage of giving the author the feeling of doing
something bad :-). Don't enforce it then, but at least encourage
it. Separating it as such will not do so.

> generate the requesters/providers, the docs can be pulled from doxygen tags.
>
> - How will the 'ServiceProvider' and 'requires' classes map to
> Interfaces? *Are* they the interface or will Interfaces and Service
> Providers both hold a reference to Operations?
>
>
> They are the Orocos representation of C++ interfaces. I.e. TaskContext -> C++
> object, Service -> C++ interface.

And how can I access an interface at runtime then? For instance if in
a smart deployer I would like to check types, arity, etc.?

> - You write:
>
> "Note that both ServiceRequester below and ServiceProvider above have
> the same name "MyService". This is how the deployment can link the
> interfaces together automatically."
>
> Will that not create the same problems as we have with AutoConnect
> and Ports now? Should there not be an explicit and semantic "type"
> which defines what can be connected sensibly?
>
>
> MyService *is* the type name of the interface. It's like agreeing on the data
> type sent over a data port. It better be identical.

Ok, I see.

> The 'automatic' kind is not so auto/proble-matic as with AutoConnect. You'll
> still have to say that A connects to B, but from there on, the matching can
> happen on service name. We'll leave the option to connect only a single service
> from A to B (instead of all possible). I see it more as a syntax thing in the
> end, not a fundamental property.

Ok, that's fine if the Service name is the type.

> - Is 'Service' a good name? It might cause confusion down the road if
> you plan to introduce something OSGi like. Or is this actually the
> first step in that direction?
>
> It is the first step. I saw no reason to name it differently. These objects
> will in time be used by the service management code. These services will be
> offered, connected, disconnected etc. I thought it was in line with naming used
> in other frameworks.

I don't know about other frameworks, but I have a feeling that the
Interfaces (ie the mostly static description of components structure)
should be seperated from the behavioural aspects of Services such as
the ability to generate events on creation, destruction, etc. The
first in only a mechanism which can be used by deployers, etc, while
the latter has a much higher "policy level".

Best regards
Markus

Ps.: Can you fix the citations of your mailer?

Example code for Proposal 2: Method/Operation/Service

On Friday 06 November 2009 11:59:11 Peter Soetens wrote:
> I've done some reshuffling of the wiki and added example code for using the
> new interfaces.
>
> http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/new-m
> ethod-operation-service-api
>
> It's clear that the amount of boilerplate code is still pretty huge. I
> think we can generate most/all of that, so we might end up with an
> rtservgen too in the end. The generator need not to be more intelligent
> than Doxygen for reading virtual function definitions in a class. Does
> orogen read virtual function definitions ?
That's not the philosophy of orogen. The philosophy of orogen is to describe
your models [here, the services] and have orogen generate the code for them.
The point being that other software now know everything there is to now about
the running *without having to parse any C++ code*.

In any case, just parsing the C++ would be useless as you also have to specify
what method runs in what threading context.

Now, for the record, I personally don't plan to use these services at all. I
have the impression that they double what TaskContext is, and that they do it
without any error reporting / state management. I.e.: bad.

Of course, if you want to add that functionality to orogen, you're most
welcome ;-)

Example code for Proposal 2: Method/Operation/Service

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

> On Friday 06 November 2009 11:59:11 Peter Soetens wrote:
> > I've done some reshuffling of the wiki and added example code for using
> the
> > new interfaces.
> >
> >
> http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/new-m
> > ethod-operation-service-api
> >
> > It's clear that the amount of boilerplate code is still pretty huge. I
> > think we can generate most/all of that, so we might end up with an
> > rtservgen too in the end. The generator need not to be more intelligent
> > than Doxygen for reading virtual function definitions in a class. Does
> > orogen read virtual function definitions ?
> That's not the philosophy of orogen. The philosophy of orogen is to
> describe
> your models [here, the services] and have orogen generate the code for
> them.
> The point being that other software now know everything there is to now
> about
> the running *without having to parse any C++ code*.
>

Oops you're right. I meant, does 'typelib' read virtual functions ?

>
> In any case, just parsing the C++ would be useless as you also have to
> specify
> what method runs in what threading context.
>

I see two solutions here: 1. specify it as a @ doxygen tag for each
operation, but that makes it globally for each component that implements it
and shows it in the API (something we wish to hide). 2. Use caller context
by default and let the component override that, ie the policy can be
dynamically changed.

>
> Now, for the record, I personally don't plan to use these services at all.
> I
> have the impression that they double what TaskContext is, and that they do
> it
> without any error reporting / state management. I.e.: bad.
>

They don't double, they replace. Which kind of error reporting / state
management is missing ? Example ?

>
> Of course, if you want to add that functionality to orogen, you're most
> welcome ;-)
>

It depends on what typelib can do.

Peter

Example code for Proposal 2: Method/Operation/Service

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

> On Friday 06 November 2009 16:14:29 you wrote:
> > On Fri, Nov 6, 2009 at 15:02, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> wrote:
> > > On Friday 06 November 2009 11:59:11 Peter Soetens wrote:
> > > > I've done some reshuffling of the wiki and added example code for
> using
> > >
> > > the
> > >
> > > > new interfaces.
> > >
> > >
> http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/new
> > >-m
> > >
> > > > ethod-operation-service-api
> > > >
> > > > It's clear that the amount of boilerplate code is still pretty huge.
> I
> > > > think we can generate most/all of that, so we might end up with an
> > > > rtservgen too in the end. The generator need not to be more
> > > > intelligent than Doxygen for reading virtual function definitions in
> a
> > > > class. Does orogen read virtual function definitions ?
> > >
> > > That's not the philosophy of orogen. The philosophy of orogen is to
> > > describe
> > > your models [here, the services] and have orogen generate the code for
> > > them.
> > > The point being that other software now know everything there is to now
> > > about
> > > the running *without having to parse any C++ code*.
> >
> > Oops you're right. I meant, does 'typelib' read virtual functions ?
> Typelib does *not* parse methods, not does it represent them. Typelib (as
> its
> name does not entirely implies) represents value-types only. Using typelib
> for
> that would be meaningless.
>
> > > In any case, just parsing the C++ would be useless as you also have to
> > > specify
> > > what method runs in what threading context.
> >
> > I see two solutions here: 1. specify it as a @ doxygen tag for each
> > operation, but that makes it globally for each component that implements
> it
> > and shows it in the API (something we wish to hide). 2. Use caller
> context
> > by default and let the component override that, ie the policy can be
> > dynamically changed.
> >
> > > Now, for the record, I personally don't plan to use these services at
> > > all. I
> > > have the impression that they double what TaskContext is, and that they
> > > do it
> > > without any error reporting / state management. I.e.: bad.
> >
> > They don't double, they replace.
> I'll write it as it came out:
>
> WHAT ??????
>
> Is that a practical joke or are you *really* trying to replace TaskContext
> ? I
> did not have that impression at all since TaskContext is mentioned in your
> examples. Could you actually be more explicit in what you are trying to
> achieve here with these services ?
>

"They don't double, they replace [ (Method,MethodRepository) +
(Command,CommandRepository) ]"

We're clearly talking next to each other here. What do you mean with
'doubles' ? The services are meant to allow automatic connection between
providers operations and requires methods during deployment. With automatic
meaning, that if a service contains 3 operations, and the user sets up a
link provider->requirer, the three methods in requirer code are
automatically connected. In practice you replace:

&#10;TaskContext* peer = this-&gt;getPeer(&quot;Camera&quot;);&#10;setShutter = peer-&gt;methods()-&gt;getMethod&lt;bool(double)&gt;(&quot;setShutter&quot;);&#10;

With:
&#10;
Yes, that's empty. We want to get rid of all this boilerplate code typically
found in configureHook(). The 'outside' connection is made similar to
connecting ports:
&#10;peer1-&gt;connectService(&quot;CameraService&quot;, peer2);&#10;// or&#10;peer1-&gt;getServiceProvider(&quot;CameraService&quot;)-&gt;connectTo(&#10;peer2-&gt;getServiceRequirer(&quot;CameraService&quot;) );&#10;// or another variant, who knows...&#10;
This is clearly done by the deployer.
At the same time, we're solving the dilemma we wrote about earlier. The
blocking/non blocking call versus caller / component thread matrix.

> > Which kind of error reporting / state
> > management is missing ? Example ?
> Well: the state machine that makes RTT have any usefulness ? I can tell you
> at
> once: you remove the TaskContext/Activity model, I either fork or go
> directly
> to ROS, because you would have removed from RTT what makes it actually
> different (and useful to me).
>

Which rules out real-time as a useful feature. Anyway. Clearly TaskContext
stays as it is. There will be an improvement in the state model, which I
didn't dare to document yet. But here I go.

The situation today is this: The TC, once created, gets a thread. We block
this thread's execution until we go from configured->activated or running.
The thing is that from activated on, we can process commands and asyn
events. That really sucks actually. For example, when we are in the
configured state, we might already like to offer some asynchronous services
(ie react to a certain event), while still rejecting some others. The
example goes like this: when you're pre-operational, you offer a broader
configuration interface then when you're running. Likewise, when you're
running, you can offer more services then when you're not configured yet.
The idea is that each ServiceProvider can be enabled or disabled according
to the provider's wishes. No more 'all or nothing' as in 1.x Commands. We
saw from actual user code, that often, the component is brought into running
asap, in order to be able to process commands and execute scripts/process
events. This hurts most of our 'standard' state machine model, since the
users try to work around it, and start defining their own
'configuration/running' states in the running state. We can't for example
write today a state machine that implements all *Hooks, which makes all
*Hooks de-facto a C++ thing. Markus, who wants to prototype a complete
component in Lua, won't be happy[*] if we don't fix this asymmetry. Of
course, scripting and whatever will be provided as services too, and you can
thus disable them in certain states, if necessary.

Another advantage of this explicit enabling/disabling of provided services
is that methods are equally easily disabled as commands today.

I hope I'm adding more clarity than clouds here...

Feel free to WHAT me again, but please don't run off to ros :-)

Peter

[*] I'm not writing on his behalf, I'm speculating :-)

Example code for Proposal 2: Method/Operation/Service

On Friday 06 November 2009 22:12:37 Peter Soetens wrote:
> On Fri, Nov 6, 2009 at 18:32, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> > On Friday 06 November 2009 16:14:29 you wrote:
> > > On Fri, Nov 6, 2009 at 15:02, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> >
> > wrote:
> > > > On Friday 06 November 2009 11:59:11 Peter Soetens wrote:
> > > > > I've done some reshuffling of the wiki and added example code for
> >
> > using
> >
> > > > the
> > > >
> > > > > new interfaces.
> >
> > http://www.orocos.org/wiki/rtt/rtt-20/provides-vs-requires-interfaces/new
> >
> > > >-m
> > > >
> > > > > ethod-operation-service-api
> > > > >
> > > > > It's clear that the amount of boilerplate code is still pretty
> > > > > huge.
> >
> > I
> >
> > > > > think we can generate most/all of that, so we might end up with an
> > > > > rtservgen too in the end. The generator need not to be more
> > > > > intelligent than Doxygen for reading virtual function definitions
> > > > > in
> >
> > a
> >
> > > > > class. Does orogen read virtual function definitions ?
> > > >
> > > > That's not the philosophy of orogen. The philosophy of orogen is to
> > > > describe
> > > > your models [here, the services] and have orogen generate the code
> > > > for them.
> > > > The point being that other software now know everything there is to
> > > > now about
> > > > the running *without having to parse any C++ code*.
> > >
> > > Oops you're right. I meant, does 'typelib' read virtual functions ?
> >
> > Typelib does *not* parse methods, not does it represent them. Typelib (as
> > its
> > name does not entirely implies) represents value-types only. Using
> > typelib for
> > that would be meaningless.
> >
> > > > In any case, just parsing the C++ would be useless as you also have
> > > > to specify
> > > > what method runs in what threading context.
> > >
> > > I see two solutions here: 1. specify it as a @ doxygen tag for each
> > > operation, but that makes it globally for each component that
> > > implements
> >
> > it
> >
> > > and shows it in the API (something we wish to hide). 2. Use caller
> >
> > context
> >
> > > by default and let the component override that, ie the policy can be
> > > dynamically changed.
> > >
> > > > Now, for the record, I personally don't plan to use these services at
> > > > all. I
> > > > have the impression that they double what TaskContext is, and that
> > > > they do it
> > > > without any error reporting / state management. I.e.: bad.
> > >
> > > They don't double, they replace.
> >
> > I'll write it as it came out:
> >
> > WHAT ??????
> >
> > Is that a practical joke or are you *really* trying to replace
> > TaskContext ? I
> > did not have that impression at all since TaskContext is mentioned in
> > your examples. Could you actually be more explicit in what you are trying
> > to achieve here with these services ?
>
> "They don't double, they replace [ (Method,MethodRepository) +
> (Command,CommandRepository) ]"
Fine, then. Just for the record, I said:
> > I have the impression that they double what TaskContext is
and you replied
> They don't double, they replace.
Hence my gut reaction. That's settled then

> We're clearly talking next to each other here. What do you mean with
> 'doubles' ? The services are meant to allow automatic connection between
> providers operations and requires methods during deployment. With automatic
> meaning, that if a service contains 3 operations, and the user sets up a
> link provider->requirer, the three methods in requirer code are
> automatically connected. In practice you replace:
>
> &#10;&gt; TaskContext* peer = this-&gt;getPeer(&quot;Camera&quot;);&#10;&gt; setShutter = peer-&gt;methods()-&gt;getMethod&lt;bool(double)&gt;(&quot;setShutter&quot;);&#10;&gt;
>
> With:
> &#10;&gt;
> Yes, that's empty. We want to get rid of all this boilerplate code
> typically found in configureHook(). The 'outside' connection is made
> similar to connecting ports:
> &#10;&gt; peer1-&gt;connectService(&quot;CameraService&quot;, peer2);&#10;&gt; // or&#10;&gt; peer1-&gt;getServiceProvider(&quot;CameraService&quot;)-&gt;connectTo(&#10;&gt; peer2-&gt;getServiceRequirer(&quot;CameraService&quot;) );&#10;&gt; // or another variant, who knows...&#10;&gt;
> This is clearly done by the deployer.
> At the same time, we're solving the dilemma we wrote about earlier. The
> blocking/non blocking call versus caller / component thread matrix.
Well. Next question: can I use methods directly without these services and
provides/requires being in the way ? My personal use of methods/commands is
that they are very specific to one component, and are accessed only by the
supervision layer. I actually don't use them in a cross-module way. That is
probably because that was the rule at LAAS, and since then I never felt I
needed it anyway. For my use case, the services would introduce a HUGE
overhead (obviously).

> The situation today is this: The TC, once created, gets a thread. We block
> this thread's execution until we go from configured->activated or running.
> The thing is that from activated on, we can process commands and asyn
> events. That really sucks actually. For example, when we are in the
> configured state, we might already like to offer some asynchronous services
> (ie react to a certain event), while still rejecting some others. The
> example goes like this: when you're pre-operational, you offer a broader
> configuration interface then when you're running. Likewise, when you're
> running, you can offer more services then when you're not configured yet.
> The idea is that each ServiceProvider can be enabled or disabled according
> to the provider's wishes. No more 'all or nothing' as in 1.x Commands. We
> saw from actual user code, that often, the component is brought into
> running asap, in order to be able to process commands and execute
> scripts/process events. This hurts most of our 'standard' state machine
> model, since the users try to work around it, and start defining their own
> 'configuration/running' states in the running state. We can't for example
> write today a state machine that implements all *Hooks, which makes all
> *Hooks de-facto a C++ thing. Markus, who wants to prototype a complete
> component in Lua, won't be happy[*] if we don't fix this asymmetry. Of
> course, scripting and whatever will be provided as services too, and you
> can thus disable them in certain states, if necessary.
Seems fine to me. Do you plan to provide the TaskContext state methods (i.e.
configure(), start(), ...) as a default "TaskContext" service that all task
contexts provide ? That would be useful to be able to asynchronously control
task contexts.

> Another advantage of this explicit enabling/disabling of provided services
> is that methods are equally easily disabled as commands today.
Well. I'm not disputing the fact that the commands/methods unification is
indeed a very useful feature.

> I hope I'm adding more clarity than clouds here...
I guess so. Especially on what you meant with "replace" ;-)
--
Dr. Ing. Sylvain Joyeux
Space and Security Robotics

DFKI Bremen
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64136
E-Mail: sylvain [dot] joyeux [..] ...

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

Example code for Proposal 2: Method/Operation/Service

On Mon, Nov 9, 2009 at 10:58, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:

> On Friday 06 November 2009 22:12:37 Peter Soetens wrote:
>
...

>
> > We're clearly talking next to each other here. What do you mean with
> > 'doubles' ? The services are meant to allow automatic connection between
> > providers operations and requires methods during deployment. With
> automatic
> > meaning, that if a service contains 3 operations, and the user sets up a
> > link provider->requirer, the three methods in requirer code are
> > automatically connected. In practice you replace:
> >
> > &#10;&gt; &gt; TaskContext* peer = this-&gt;getPeer(&quot;Camera&quot;);&#10;&gt; &gt; setShutter = peer-&gt;methods()-&gt;getMethod&lt;bool(double)&gt;(&quot;setShutter&quot;);&#10;&gt; &gt;
> >
> > With:
> > &#10;&gt; &gt;
> > Yes, that's empty. We want to get rid of all this boilerplate code
> > typically found in configureHook(). The 'outside' connection is made
> > similar to connecting ports:
> > &#10;&gt; &gt; peer1-&gt;connectService(&quot;CameraService&quot;, peer2);&#10;&gt; &gt; // or&#10;&gt; &gt; peer1-&gt;getServiceProvider(&quot;CameraService&quot;)-&gt;connectTo(&#10;&gt; &gt; peer2-&gt;getServiceRequirer(&quot;CameraService&quot;) );&#10;&gt; &gt; // or another variant, who knows...&#10;&gt; &gt;
> > This is clearly done by the deployer.
> > At the same time, we're solving the dilemma we wrote about earlier. The
> > blocking/non blocking call versus caller / component thread matrix.
> Well. Next question: can I use methods directly without these services and
> provides/requires being in the way ? My personal use of methods/commands is
> that they are very specific to one component, and are accessed only by the
> supervision layer. I actually don't use them in a cross-module way. That is
> probably because that was the rule at LAAS, and since then I never felt I
> needed it anyway. For my use case, the services would introduce a HUGE
> overhead (obviously).
>

Assuming that you are using CORBA to invoke these methods/commands, there
will be a 'usable without Orocos' CORBA interface for operations. Most
users valued this enormously in 1.x, even in it's limited state it is in
today. The idea is that adding an operation (former method/command) to a TC
interface is as easy/easier as in 1.x. Since the TC has a default
interface/service, you can attach anything in there like in 1.x. We're *not*
going to force you into a system design that says: 'you must define
everything in a C++ interface, then create/generate a service object, then
add that object'. Instead, you can easily add operations along the way too,
just like before. In your case:

When you wrote in 1.x:
&#10;    RTT::Command&lt;bool(int,double)&gt; mycom;&#10;    //...&#10;    MyTC: TaskContext(&quot;MyTC&quot;), mycom(&quot;command&quot;, &amp;foo, &amp;foo_compl) {&#10;         this-&gt;commands()-&gt;addCommand(&amp;mycom, &quot;Descr&quot;, &quot;a1&quot;, &quot;a1 descr&quot;,&#10;&quot;a2&quot;, &quot;a2 descr&quot;);&#10;   }&#10;
You'll write in 2.x:
&#10;    MyTC: TaskContext(&quot;MyTC&quot;) {&#10;         this-&gt;provides()-&gt;newOperation(&quot;operation&quot;,&amp;foo).doc(&quot;Descr&quot;, &quot;a1&quot;,&#10;&quot;a1 descr&quot;, &quot;a2&quot;, &quot;a2 descr&quot;);&#10;   }&#10;

And "operation" will be ready to use from the CORBA and any other interface.
I don't see any HUGE (nor huge) overhead. But I might be missing something
here.

>
> > The situation today is this: The TC, once created, gets a thread. We
> block
> > this thread's execution until we go from configured->activated or
> running.
> > The thing is that from activated on, we can process commands and asyn
> > events. That really sucks actually. For example, when we are in the
> > configured state, we might already like to offer some asynchronous
> services
> > (ie react to a certain event), while still rejecting some others. The
> > example goes like this: when you're pre-operational, you offer a broader
> > configuration interface then when you're running. Likewise, when you're
> > running, you can offer more services then when you're not configured yet.
> > The idea is that each ServiceProvider can be enabled or disabled
> according
> > to the provider's wishes. No more 'all or nothing' as in 1.x Commands. We
> > saw from actual user code, that often, the component is brought into
> > running asap, in order to be able to process commands and execute
> > scripts/process events. This hurts most of our 'standard' state machine
> > model, since the users try to work around it, and start defining their
> own
> > 'configuration/running' states in the running state. We can't for example
> > write today a state machine that implements all *Hooks, which makes all
> > *Hooks de-facto a C++ thing. Markus, who wants to prototype a complete
> > component in Lua, won't be happy[*] if we don't fix this asymmetry. Of
> > course, scripting and whatever will be provided as services too, and you
> > can thus disable them in certain states, if necessary.
> Seems fine to me. Do you plan to provide the TaskContext state methods
> (i.e.
> configure(), start(), ...) as a default "TaskContext" service that all task
> contexts provide ? That would be useful to be able to asynchronously
> control
> task contexts.
>

Yes. They will remain. I can't repeat myself enough: we only break
backwards compatibility if we really *must*. configure/start/stop, the
hooks etc remain in place in 2.0.

>
> > Another advantage of this explicit enabling/disabling of provided
> services
> > is that methods are equally easily disabled as commands today.
> Well. I'm not disputing the fact that the commands/methods unification is
> indeed a very useful feature.
>
> > I hope I'm adding more clarity than clouds here...
> I guess so. Especially on what you meant with "replace" ;-)
>

So I assume you consider to stay then ? Good ! ;-)

Peter