[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Example code for Proposal 2: Method/Operation/Service
From:       markus.klotzbuecher () mech ! kuleuven ! be (Markus Klotzbuecher)
Date:       2009-11-10 11:24:04
Message-ID: 20091110112306.GB4518 () x61 ! spaceport9
[Download RAW message or body]

On Tue, Nov 10, 2009 at 10:00:10AM +0100, Peter Soetens wrote:
> On Tue, Nov 10, 2009 at 08:55, Markus Klotzbuecher <
> markus.klotzbuecher at mech.kuleuven.be> 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?

[prev in list] [next in list] [prev in thread] [next in thread]