[PATCH] for the bug 802

Hi RTT-devs.

I'am trying to make a patch for the bug '802 : Test if a peer has an operation/property'.

I submit you a first attempt. For ports, attributes and properties, it should be ok. But for operations it's not definitive.

I need your help because i don't understand the Service + Operation philosophy.

I add an hasOperation method to the TaskContext class. But i can't implement it with (Service::getOperation != 0) because the behavior should be different (mustn't display the message). Moreover i can't implement a Service::hasOperation because it already exists.

The problem is that the Service seems to have two kind of operations. The Service's methods hasOperation and getOperationNames for example work on its simpleoperation member, and, getOperation for example work on its OperationInterface base class.

In hasOperation and getOperationNames, the calls to OperationInterface (hasMembers and getNames) are commented out. So i would like to have a bit of history on what happened here :

 - should the getOperation method take care of simpleoperation ?
 - should the hasOperation method take care of OperationInterface ?
 - isn't it possible to have only one type of operation ? 
I found the current implementation very complicated.

I add an other little patch for passing strings by reference to function of task context.

Regards.

Paul.

AttachmentSize
orocos-rtt-2.2.0-add_has_something.patch3.1 KB
orocos-rtt-2.2.0-const_string_ref.patch7.62 KB

[PATCH] for the bug 802

On Wednesday 26 January 2011 10:46:56 paul [dot] chavent [..] ... wrote:
> Hi RTT-devs.
>
> I'am trying to make a patch for the bug '802 : Test if a peer has an
> operation/property'.

To first set a misunderstanding straight, If you want to check for a peer's
property/operations etc, you need to call:


peer->provides()->hasProperty("foo")
peer->provides()->hasOperation("bar")


provides() returns the Service Object you want to query. Since a component can
have multiple services, a global 'TaskContext::hasProperty' function is not
meaningful, since it would only be able to query the 'top level'/'this'
service of the component, and not any subservice. While with provides, you
would write:


peer->provides("scripting")->hasOperation("runScript")


So I'm not eager to add these functions to TaskContext.hpp.

>
> I submit you a first attempt. For ports, attributes and properties, it
> should be ok. But for operations it's not definitive.
>
> I need your help because i don't understand the Service + Operation
> philosophy.
>
> I add an hasOperation method to the TaskContext class. But i can't
> implement it with (Service::getOperation != 0) because the behavior should
> be different (mustn't display the message). Moreover i can't implement a
> Service::hasOperation because it already exists.
>
> The problem is that the Service seems to have two kind of operations. The
> Service's methods hasOperation and getOperationNames for example work on
> its simpleoperation member, and, getOperation for example work on its
> OperationInterface base class.

Correct. We keep track of both C++ operations and of 'remote' operations with
the same object (Service). When a local C++ operation is added, it appears in
both lists, if a remote operation is added (or a script function for example)
it only apears in the 'remote' list.

>
> In hasOperation and getOperationNames, the calls to OperationInterface
> (hasMembers and getNames) are commented out. So i would like to have a bit
> of history on what happened here : - should the getOperation method take
> care of simpleoperation ?
> - should the hasOperation method take care of OperationInterface ?
> - isn't it possible to have only one type of operation ?
> I found the current implementation very complicated.

It's because you're touching the first layers of the 'middleware' aspect in
RTT. At some point, we distinguish between local operations and remote ones.
hasOperation() only returns true if the operation is local in this component
or in this process. Meaning if you call it on a peer component, it might
return false always (because the peer is in another process for example).
hasMember() checks for the operation across processes.

Now I think myself this makes no sense to Joe user. So what I propose is this:

In OperationInterface.hpp:
-> leave hasMember for what it is, but deprecate it in the doxygen docs in
favour of hasPart():
-> add hasPart to OperationInterface.hpp which does exactly the same as
hasMember()
In Service.hpp:
-> rename hasOperation() to hasLocalOperation(). You'll need to rename them
too in ServiceRequester.cpp, Service.cpp and StateGraphParser.cpp
-> add a new function hasOperation() that returns hasPart(). Rationale: if
hasOperation() returns true, every OperationCaller object will be able to call
it (it will be a local or remote operation).

The idea is then that every mortal user uses hasOperation() and only framework
developers use hasLocalOperation() or hasPart() when they need to know if an
operation is local or remote.

>
> I add an other little patch for passing strings by reference to function of
> task context.

Thanks for your attention to detail and API review.

Peter

Re: [PATCH] for the bug 802

Here are some patches. Could you tell me if it is on the good way please ?

Re: [PATCH] for the bug 802

Hello Peter.

Sorry to have let so much time without answer.

Thanks to your previous message, I think i understand the local and remote operation distinction.

But i still have a question about that :

peter wrote:
To first set a misunderstanding straight, If you want to check for a peer's property/operations etc, you need to call:

peer->provides()->hasProperty("foo")
peer->provides()->hasOperation("bar")

provides() returns the Service Object you want to query. Since a component can have multiple services, a global 'TaskContext::hasProperty' function is not meaningful, since it would only be able to query the 'top level'/'this' service of the component, and not any subservice. While with provides, you would write:

peer->provides("scripting")->hasOperation("runScript")

So I'm not eager to add these functions to TaskContext.hpp.

I decided to not use sub-services for my components. So I always add an operation "directly" to the component with this->addOperation( "reset",  &MyTask::reset, this, OwnThread).doc("Reset the system."); for example. So when i want to use this operation in an other component i do OperationCaller<void(void)> my_reset_meth = a_task_ptr->getOperation("reset");. So i would like to have a hasOperation() in Taskcontext or remove the getOperation() and always use provides() for querying services.

In your previous mail i understand the modification you wish for OperationInterface and Service. But i don't understand what do you want for TaskContext ?

Thank you for your help.

Paul.

[PATCH] for the bug 802

Hi RTT-devs.

I'am trying to make a patch for the bug '802 : Test if a peer has an operation/property'.

I submit you a first attempt. For ports, attributes and properties, it should be ok. But for operations it's not definitive.

I need your help because i don't understand the Service + Operation philosophy.

I add an hasOperation method to the TaskContext class. But i can't implement it with (Service::getOperation != 0) because the behavior should be different (mustn't display the message). Moreover i can't implement a Service::hasOperation because it already exists.

The problem is that the Service seems to have two kind of operations. The Service's methods hasOperation and getOperationNames for example work on its simpleoperation member, and, getOperation for example work on its OperationInterface base class.

In hasOperation and getOperationNames, the calls to OperationInterface (hasMembers and getNames) are commented out. So i would like to have a bit of history on what happened here :
- should the getOperation method take care of simpleoperation ?
- should the hasOperation method take care of OperationInterface ?
- isn't it possible to have only one type of operation ?
I found the current implementation very complicated.

I add an other little patch for passing strings by reference to function of task context.

Regards.

Paul.