Re: RTT-Introspection and how to do it ?

2015-03-26 1:15 GMT+01:00 Sylvain Joyeux <[email protected]>:

> > 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
>

I'm not sure sarcasm will help in any way ... It's a public discussion btw
...


>
>    > 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
>

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