Re: RTT-Introspection and how to do it ?

> Your proposal won't work in the case that the peer mechanism is used, and
> the connections are created inside of a task. It also won't work, if the
> connections are created inside a deployment using connect_to directly.

And why is that ? connectTo can fill the information in the "I don't
use the tooling case". But that's for another point later.

> It will also fail in the corba renaming scenario, if the renaming is done
> after the connect, as wrong information is stored in the policy.
Interesting. Not a case we have right now, but interesting.

> Your proposal will also only work if you use enabled tooling, that fills in
> the information. And as the filled in information is not standardized through an proper
> interface, it will only be useful to the introspection tool for the specific tooling.
> Wouldn't it be better if there would be one tool, for RTT, that would work
> regardless of the tooling ?

Better ? It depends on the cost on (1) RTT and (2) the various
toolchains. What is this "introspection tool" exactly doing ?
Explaining that would help understanding where you're trying to go.

> You clearly did not understand the proposal. The getURI returns the URI of
> the remote counterpart of the channel element. This information can then be used to
> trace back the connections. And this information is 100% available inside of the
> channel element, regardless of the tooling you use, because it is transport specific.
Definitely an interesting idea. However, I don't see what you would
use as "transport-dependent URI"
 CORBA: the IOR, but of what? Ports don't have a IOR.
DataFlowInterface has one, but that's already two
           steps further from the endpoint. And the Channel endpoints
are hidden deep inside the channel itself              (a.k.a. not
known from the outside)
 MQ: the mq name itself ?
 ROS: the topic name ? But then that won't work if you have multiple ROS masters

If your idea is to provide an ID that can be matched externally to
rebuild the graph later, then simply generating a UUID per channel
would do the trick (just noticed Peter's message in the github thread
... he was suggesting that already, missed it somehow :(). However,
that's not working in the stream case (e.g. ROS) as there is no other
endpoint to "match" against.

<ironic>
You could even store the UUID in the policy metadata
</ironic>

> As you may recall my first patch tried to to just that. Fill in task and
> port names. And you may also recall that is was quite intrusive. So to quote you, there
> is no way to fill in the default information without a lot of 'mumbojumbo'.
Nice out-of-context quote. You should try and go into journalism. The
whole quote was

   > The only thing you need to update is your implementation of TaskProxy.
   > It has all the information needed to set the policy field properly without
   > adding a lot of mumbo-jumbo in
   > RTT itself.

Which was mainly referring to the fact that you were propagating port
and task names all the way through the channels and CORBA IDL ! If you
limit yourself to connectTo in "plain RTT" and in the corba proxies,
that would be a lot less intrusive and would provide the
fill-in-the-defaults quite nicely.

> What I'm trying to do is to find a lightweight solution, that will work in
> all cases.
> For some reasons, you seem to take this personal.
You interpreted it wrong. What you see here is "very annoyed" by
wasting my time talking to a wall. For. So. Many. Emails.

But at least it got you talking.

Sylvain
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev