On Thursday, August 14, 2008, at 09:34AM, "Peter Soetens"
<peter [dot] soetens [..] ...> wrote:
>On Thursday 14 August 2008 15:15:01 S Roderick wrote:
>>
>> > [...sorry for the orocos-dev talk below...]
>> > A 'simple' solution to this port problem is to add the
>> > buildDataPort(std::string name)/buildBufferPort methods to the
>> > CorbaTemplateProtocol.hpp class. Then the proxy can create these
>> > ports right
>> > away and they will be 'strong'.

I am fairly sure I won't like the answer to this .... but what would be involved with doing the above?

>> > Maybe the latter solution is what you hoped would be present in the
>> > ControlTaskProxy ?
>>
>> Yes, I think this is what I had in mind! This was also brought up in
>> the other post I did several weeks back, but we never resolved it.
>>
>> Simply put, I want to access a proxy's data ports without having to
>> connect another port to it. This is the weak vs strong bit above I
>> think.
>
>Exactly. Today, It only works like in the example of my other mail. In order
>to write something like
>
> PortInterface* the_port = proxy->ports()->getPort("the_port");
> DataPort data_port = dynamic_cast >(the_port);
> data_port->Set( 3.0 ); // write directly, bypassing the connection object
>
>...we'd need to change the .idl interface, because today we only allow access
>over connection objects (using 'createDataChannel'), which guard
>thread-safeness for remote calls.

As a matter of interest, the above code works correctly even it not called from within a task context, right?

>Why don't want you to connect using a connection object to the port from the
>GUI ?

Huh? What do you mean? So, what is the relationship between connection objects and data ports?

>> At the moment, it appears to me that the GUI app will have to write
>> code to individually pull out each method/port/etc from the proxy
>> object that it needs (with calls like proxy->ports()->getPort("data")
>> or proxy->methods->getMethod<>(), etc). This is workable, but it
>> essentially means you are reproducing the individual items from the
>> remote component's interface (ie you are manually reproducing the
>> interface). Slightly painful.
>
>However painful, it is the 'recommended' way of communicating between any 2
>components in Orocos, such that network distribution is completely
>transparant. It doesn't scale 'very' well, but it is the only option we have
>in C++ (other than using code generation, which is what CORBA does),
>otherwise, we'd need to revisit Objective-C, which has all these features as
>a part of the language :-]

Understood. IDL's are usually not fun to deal with ...

>> Hence the overall question of "structure" that prompted this thread. I
>> can't find any example code anywhere, except buried in taskbrowser, of
>> how to do this in a real situation.
>
>The taskbrowser is the worst teacher you could find :-) I now realise that
>this kind of 'application building' howto should contain such examples,
>especially when CORBA gets involved.

Actually, I did want to bring that up. I think we (the project) should consider adding some more application-centered examples. These should be complete examples, more like tutorials, of some of these concepts that are very common and every newcomer ends up trying to figure out. The existing example code is decent, however, it doesn't get you to the level of a fully integrated application. Also, unfortunately, some of the code is obsolete or doesn't compile.

S

> As I said in my previous mail, I don't understand the exact problem
> you're
> having. Data Ports are the only 'weak' elements in the
> ControlTaskProxy in
> the sense that they can not accept/return data until they are
> connected with
> a local data port.Also, getting an 'anticlone()' of a CorbaPort just
> returns
> the same weak object. The other parts (methods, properties,
> commands) of the
> ControlTaskProxy work fine, except events, which are not supported
> in CORBA.

So for a method call, is it something like this?

m = proxy->methods()->getMethod<...>("somemethod")
m(...)

Ports is what I'm struggling with ...

> [...sorry for the orocos-dev talk below...]
> A 'simple' solution to this port problem is to add the
> buildDataPort(std::string name)/buildBufferPort methods to the
> CorbaTemplateProtocol.hpp class. Then the proxy can create these
> ports right
> away and they will be 'strong'.
>
> Maybe the latter solution is what you hoped would be present in the
> ControlTaskProxy ?

Yes, I think this is what I had in mind! This was also brought up in
the other post I did several weeks back, but we never resolved it.

Simply put, I want to access a proxy's data ports without having to
connect another port to it. This is the weak vs strong bit above I
think.

Given these components at the remote end

CORBA - user-interace - multiple control components - robot component

I want at the GUI

GUI code - user-interface-proxy - CORBA

and be able to write code to use the user-interface-proxy exactly like
I would if the GUI code was connected directly to the user-interface
component (ie they were in the same application). Now I completely
understand that this is an ideal concept, and most likely won't work
like that in reality, but I'm trying to find the most straight forward
way to do this.

At the moment, it appears to me that the GUI app will have to write
code to individually pull out each method/port/etc from the proxy
object that it needs (with calls like proxy->ports()->getPort("data")
or proxy->methods->getMethod<>(), etc). This is workable, but it
essentially means you are reproducing the individual items from the
remote component's interface (ie you are manually reproducing the
interface). Slightly painful.

Hence the overall question of "structure" that prompted this thread. I
can't find any example code anywhere, except buried in taskbrowser, of
how to do this in a real situation.

HTH
S

PS: I do realise I'm not suggesting any solutions here. I'm still
trying to understand the structure of the underlying problem. :-(

>> Ahhhh ... that makes sense. Using the native method/data-flow calls
>> on
>> the corba interface is nothing but ugly, unfortunately. :-( The
>> scripting interface part might make life easier, we'll check it out.
>> Thanks!
>
> If you could write down a scenario (ie code) which you'd like to use
> client
> side to read/write ports. That could help as well to quickly find a
> better
> solution.
>
>>
>> So, is there no way to get a proxy of a component that has the same
>> C+
>> + interface as the remote component? This would allow you to directly
>> access the C++ ports, methods, etc of the component (proxy) directly?
>
> You mean, another one than ControlTaskProxy ? I don't understand this
> question.

Here's what I've got in my mind ....

At the remote end:

class MyTask : public RTT::TaskContext
{
RTT::Method<...> reset_mtd;
RTT::ReadDataPort<...> data_port;
...
}

and remote code that can do

mytask_ptr->reset_mtd()
x = mytask_ptr->data_port.Get()

I ideally want to do exactly that at the local (GUI) end, starting
from a proxy TaskContext.

proxy = Corba:ControlTaskProxy::Create("MyTask")
proxy->reset_mtd()
x = proxy->data_port.Get()

The problem is that proxy is a TaskContext* and not a MyTask*, so it
is a generic object with no idea of the additional methods/data in the
MyTask object at the remote end. So question is, how do I either cast
proxy to a MyTask*, or access the ports and methods of MyTask from the
"TaskContext* proxy".

So far, I'm monkeying with something like

proxy = Corba:ControlTaskProxy::Create("MyTask")
PortInterface* data_port = proxy->ports()->getPort("data");
CorbaPort* r = dynamic_cast(data_port);
AssignableExpression_ptr a = r->getDataChannel();
... and trying to figure out here how to use "a" to do the equivalent
of "proxy->data.Get()" ...

I can't find an example of how to actually use the proxy object to
gain access to the remote's methods/commands/properties/ports/etc. So
far, the above rather ugly code is the only viable path I can find.

Where am I going wrong?

TIA
S

On Thursday 14 August 2008 15:02:03 S Roderick wrote:
> > You mean, another one than ControlTaskProxy ? I don't understand this
> > question.
>
> Here's what I've got in my mind ....
>
> At the remote end:
>
> class MyTask : public RTT::TaskContext
> {
> RTT::Method<...> reset_mtd;
> RTT::ReadDataPort<...> data_port;
> ...
> }
>
> and remote code that can do
>
> mytask_ptr->reset_mtd()
> x = mytask_ptr->data_port.Get()
>
> I ideally want to do exactly that at the local (GUI) end, starting
> from a proxy TaskContext.
>
> proxy = Corba:ControlTaskProxy::Create("MyTask")
> proxy->reset_mtd()
> x = proxy->data_port.Get()
>
> The problem is that proxy is a TaskContext* and not a MyTask*, so it
> is a generic object with no idea of the additional methods/data in the
> MyTask object at the remote end. So question is, how do I either cast
> proxy to a MyTask*, or access the ports and methods of MyTask from the
> "TaskContext* proxy".

This is how for methods:
// use exactly the same as for plain C++ objects:
Method<...> the_meth = proxy->methods()->getMethod<...>("reset_meth");

// calls reset_meth:
the_meth();

Commands, properties and attributes work like-wise.

This is how for ports:

// create a local port
DataPort the_port;
// get the remote port
PortInterface* remote_port = proxy->ports()->getPort("data_port");

// Connect them. the connection direction (R<->W) is figured out by Orocos
the_port.connectTo( remote_port);

// Send over data to remote side
the_port.Set( 3.0 );

// Read data from remote side
d = the_port.Get();

Simple enough ?

Peter