Re: RTT-Introspection and how to do it ?

Am 26.03.2015 um 01:37 schrieb Willy Lambert:
>
>
> 2015-03-26 1:15 GMT+01:00 Sylvain Joyeux <[email protected] 
> <mailto:[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.
>
Actually no. In the case of connect_to to a remote port, the remote port
is created by the TaskContextServer and attached to the local task.
This is some sort of trick there... At this point, you have no chance to
figure out the name of the original task, if you don't propagate the 
information
all along the way like my first patch did.
>
>
>     > 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.
>
Is that clear now from the explanation below, or should I retry ?
>
>
>     > 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.
>
Rethinking it a bit, we would need 2 methods getLocalURI, getRemoteURI.
in the connection tracking it then comes down to a simple string match.
The URI could also be a unique identifier / UUID.
>
>     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)
>
Hu ? I can iterate the channel elements by  using the getInput and 
getOutput methods.
>
>      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.
>
The output graph of the tracking class would contain the Tasks, the 
Ports and the
channel elements. If there is no remote matched one, it will still be in 
there as a
leaf with the URI/UUID. So the information in the leaf can be used to 
figure out
the ROS endpoint.
Interestingly enough, this would also work in the case, were a port is 
publishing
to a ROS topic, and multiple other ports are subscribed to the same ROS 
topic.
>
>
>     <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.
>
As I said above, there is not simple way to archive this. Feel free to 
prove me wrong...
Anyway, I would prefer the conn tracking solution, it seems simpler and 
would
provide the ability to inspect the buffer fill levels inside of the 
connections.
     Janosch

>
>     > 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]
>     <mailto:[email protected]>
>     http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>


-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-6614
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  [email protected]

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

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