Hello.
As you say, a ServiceRequester is the syletric of a Service(Provider). We can add operation, ports and operation to a Service. I would like to be able to do the same think on the other side and connect them when i call connectTo from the Requester.
I would like to modify the ServiceRequester and submit you a patch. But before, i would like to have your opinion : Why haven't you done this ? Is there any conception pitfall i don't see ?
Thank you for your suggestion.
Paul.
I would like to extend the ServiceRequester.
Hello Peter.
Yes it's my case.
My use case is to define one Provider with OperationInterface, ConfigurationInterface and DataFlowInterface, on one hand and the same thing on the other.
Till now, i do this with a class that contain OperationCallers, Properties, and Ports. I "connected" the operation with getOperation, the properties with getProperty, and ports with getPort+connectTo.
But i ran in trouble with the ports : i have a segfault when i connect a port without DataFlowInterface. So I thought that it would be more elegant to use RTT::Service. But RTT::Service is in fact a ServiceProvider and is not "really" symetric. Its alter-ego is ServiceRequester. That why i would like to see approximately the same thing on the requester side.
That is the rationale of my need. Tell me if it's ok.
Furthermore, there are some questions in suspend :
(1) My problem of ports won't be resolved while i can't attach my port to a DataFlowInterface. So, should ServiceRequester inherit of the three Interface, like Service ?
(2) When i do requires("robot")->connectTo(peer>provides("robot")), how i connect ports ? The quick answer is that i add an optional parameter to connectTo that take a policy. The problem is that i can't fine-grain setup the policy of each ports of the service.
(3) The other question is : in ServiceRequester::connectTo there is a warning if the requester haven't any owner. Till now i used to connect operation with getOperation and i didn't need any TaskContext to call the operation. Is it still the case with the ServiceRequester ?
Thank you Peter for considering this.
Paul.
========================================
Message du 18/11/10 10:17
De : "Peter Soetens"
A : orocos-dev [..] ..., paul [dot] chavent [..] ...
Copie à :
Objet : Re: [Orocos-Dev] I would like to extend the ServiceRequester.
On Thursday 18 November 2010 09:15:43 paul [dot] chavent [..] ... wrote:
> Hello.
>
> As you say, a ServiceRequester is the syletric of a Service(Provider). We
> can add operation, ports and operation to a Service. I would like to be
> able to do the same think on the other side and connect them when i call
> connectTo from the Requester.
>
> I would like to modify the ServiceRequester and submit you a patch. But
> before, i would like to have your opinion : Why haven't you done this ? Is
> there any conception pitfall i don't see ?
>
I was waiting for a patch :-) There is no conceptual objection against it. The
main reason it's not there yet is that in the beginning, Services only
contained operations, and not ports. That's why you can only add operation
callers to service requesters. You can extend it with adding ports, but note
that connecting ports should be already easy from a script or XML. What you
add is connecting 'whole' interfaces with one command... is that your usecase
?
Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
I would like to extend the ServiceRequester.
On Thursday 18 November 2010 12:01:35 paul [dot] chavent [..] ... wrote:
> Hello Peter.
>
> Yes it's my case.
>
> My use case is to define one Provider with OperationInterface,
> ConfigurationInterface and DataFlowInterface, on one hand and the same
> thing on the other.
>
> Till now, i do this with a class that contain OperationCallers, Properties,
> and Ports. I "connected" the operation with getOperation, the properties
> with getProperty, and ports with getPort+connectTo.
>
> But i ran in trouble with the ports : i have a segfault when i connect a
> port without DataFlowInterface. So I thought that it would be more elegant
> to use RTT::Service. But RTT::Service is in fact a ServiceProvider and is
> not "really" symetric. Its alter-ego is ServiceRequester. That why i would
> like to see approximately the same thing on the requester side.
>
> That is the rationale of my need. Tell me if it's ok.
>
> Furthermore, there are some questions in suspend :
>
> (1) My problem of ports won't be resolved while i can't attach my port to a
> DataFlowInterface. So, should ServiceRequester inherit of the three
> Interface, like Service ?
This is something I overlooked. It's very likely that it will have to inherit
from DataFlowInterface too. That class assumes it's part of a Service (for
adding the port operations read/write/etc...). I mean, say that it all works,
how would you read/write that port from within a script ? The TaskContext C++
code can do a getProvider<MyRequester>("myrequester")->port_a.read(...), but a
script goes through a service, not a service requester (yet).
>
> (2) When i do requires("robot")->connectTo(peer>provides("robot")), how i
> connect ports ? The quick answer is that i add an optional parameter to
> connectTo that take a policy. The problem is that i can't fine-grain setup
> the policy of each ports of the service.
You could extend the service requester to store policies for each listed port,
or pass that as a parameter to connectTo.
>
> (3) The other question is : in ServiceRequester::connectTo there is a
> warning if the requester haven't any owner. Till now i used to connect
> operation with getOperation and i didn't need any TaskContext to call the
> operation. Is it still the case with the ServiceRequester ?
Hmm. The reason we need a TaskContext (the owner) is that we need an
ExecutionEngine that catches asynchronous completions of operations. If no
owner is present, the GlobalExecutionEngine is used, which is fine, but we need
more 'experience' (unit tests) to see if this will always work in all cases.
However *if* you call an operation from within a TaskContext and you *don't*
set the owner, your operation may hang forever, since the GlobalEE will be
notified of the completion, and not your own TaskContext. Nothing to worry
about for now though.
Peter
I would like to extend the ServiceRequester.
On Thursday 18 November 2010 09:15:43 paul [dot] chavent [..] ... wrote:
> Hello.
>
> As you say, a ServiceRequester is the syletric of a Service(Provider). We
> can add operation, ports and operation to a Service. I would like to be
> able to do the same think on the other side and connect them when i call
> connectTo from the Requester.
>
> I would like to modify the ServiceRequester and submit you a patch. But
> before, i would like to have your opinion : Why haven't you done this ? Is
> there any conception pitfall i don't see ?
>
I was waiting for a patch :-) There is no conceptual objection against it. The
main reason it's not there yet is that in the beginning, Services only
contained operations, and not ports. That's why you can only add operation
callers to service requesters. You can extend it with adding ports, but note
that connecting ports should be already easy from a script or XML. What you
add is connecting 'whole' interfaces with one command... is that your usecase
?
Peter
Hello Peter.I'm dissecting
Hello Peter.
I'm dissecting the Services. I wonder why Service::provides() return a shared pointer and ServiceRequester::request() return a pointer ?
Hello Peter.I'm dissecting
Hello Peter.
I'm dissecting the Services. I wonder why Service::provides() return a shared pointer and ServiceRequester::request() return a pointer ?
Hello Peter.I'm dissecting
On Friday 19 November 2010 08:13:23 paul [dot] chavent [..] ... wrote:
> Hello Peter.
>
> I'm dissecting the Services. I wonder why Service::provides() return a
> shared pointer and ServiceRequester::request() return a pointer ?
The shared_ptr is certainly necessary because there's shared ownership. For
ServiceRequester, we didn't have that complexity. If you want to try to change
it to shared_ptr, you'll have to apply the 'enable_shared_from_this' trick too
in ServiceRequester (identical to Service).
Peter
Hello Peter.I'm
Could you explain me something please.
When, for example, we do addOperation to a service, we give an instance and an implementation. I can understand that two task context share the implementation, but, i don't understand in which case the operation could be called with the same object for two different task context ? The same thing apply for ports, does it means that the two task context share the same port interface ?
Hello Peter.I'm dissecting
Could you explain me something please.
When, for example, we do addOperation to a service, we give an instance and an implementation. I can understand that two task context share the implementation, but, i don't understand in which case the operation could be called with the same object for two different task context ? The same thing apply for ports, does it means that the two task context share the same port interface ?
Hello Peter.I'm
On Sat, Nov 20, 2010 at 11:22 AM, <paul [dot] chavent [..] ...> wrote:
> Could you explain me something please.
>
> When, for example, we do addOperation to a service, we give an instance and an implementation. I can understand that two task context share the implementation, but, i don't understand in which case the operation could be called with the same object for two different task context ? The same thing apply for ports, does it means that the two task context share the same port interface ?
The answer/reason is C++ technical. We need a pointer to the class
that implements the operation 'foo'. We have a pointer to a
'TaskContext', but not to its subclass, nor do we know the type of the
subclass, so we can't dynamic cast to it. The reasonable thing to do
is to have the user pass the 'this' pointer.
We could invent a 'trick' which deduces the class type from the
operation's signature, ie when we pass '&MyComponent::foo' as argument
to addOperation, we can deduce that the TaskContext is of type
'MyComponent' and could try to cast the 'this' pointer of the
TaskContext to that type.
That doesn't entirely answer your question. I would not recommend to
share one object (whose functions you want to add as operations)
between *two* taskcontexts, but you are certainly allowed to add
functions of another object than a TaskContext.
If you want two tasks to share the same port interface, they can not
share the same instances. Ie, a port object can only belong to one
taskcontext. Two tasks can provide the same service, and as such offer
the same ports from an interface perspective, but not literally share
the same objects. This would break severely encapsulation of
components, and the code assumes that all these primitives have
exactly one owner (this was not necessarily the case in RTT 1.x)
Peter