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?

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:

TaskContext* peer = this->getPeer("Camera");
setShutter = peer->methods()->getMethod<bool(double)>("setShutter");

With:

peer1->connectService("CameraService", peer2);
// or
peer1->getServiceProvider("CameraService")->connectTo(
peer2->getServiceRequirer("CameraService") );
// or another variant, who knows...

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