Re: RTT-Introspection and how to do it ?

Am 25.03.2015 um 20:29 schrieb Sylvain Joyeux:
> 2015-03-25 12:25 GMT-03:00 Janosch Machowinski <[email protected]>:
>> To gather the introspection information, the TaskContextServer (or
>> whatever else you use) would need to iterate over the channel elements
>> of the ConnectionManager and output it. Big plus, of there is a
>> BufferChannelElement in between, one could also ask it for its
>> fill status.
>> Thoughts on this ?
> Could you *please* start by saying what is your problem with the
> solution I've proposed, apart from it being coming from me ? I
> literally spend hours and lots of (virtual) ink trying to tell you why
> I don't like your solution. The only thing I get back is two lines ("I
> don't like X because it would require me to modify the proxies", yes,
> and ?)
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.
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.

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 ? I'm thinking of a class, that you give a 
bunch of
TraceFoo<Tooling specific templateClass, TaskContext> that returns you
a Graph of  the same template class. Also, I don't see the need for this 
class
to go inside of the RTT code...
>
> To make things absolutely clear: to me, the way it is coded is not the
> main issue. The *concept* of how you want to implement this little
> part of "introspection" is the issue. Having a getURI method or moving
> strings around do not change the underlying problem: such an API has
> no place in RTT.  *Nothing* beats leaving toolchain concerns to the
> toolchain. Identifying tasks and ports ? That's a toolchain concern,
> you do NOT know how toolchains might want to represent and resolve
> tasks and ports. Heck, you did not seem to know how orocos.rb was. And
> it avoids bogging RTT's code, which is already complex enough.
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.
>
> To add insult to injury, you seem determined to pass on the
> opportunity of creating a cheap way to store and retrieve
> channel-specific metadata.
>
> What's wrong with filling default values with something RTT already
> has (task and port names) if the expected field(s) are not already
> filled exactly? You get what you want and so do I: the flexibility of
> giving the toolchain(s) to do their job while still providing a
> low-level functionality that is limited but "works" (for a limited
> meaning of "works").
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'.
>
> (Again: how do you deal with multiple naming services ? Multiple ROS
> servers ? You would have to "feed" that information to RTT, which
> either means modifying the tooling to do it (!) but still telling RTT
> that he has to ignore it (i.e. creating a way for the toolchain to
> store a URI that is tooling-specific *and* provide "on the side" the
> name RTT expects) or moving a multi-NS system into RTT. Yuk.)
Needs to be resolved by the introspection tool, by using the Tooling 
specific information
mentioned above.
>
> In other words, you force your vision of how RTT should be used on the
> developers (present and future) of the toolchains using RTT. Which is
> exactly what RTT succeeded in avoiding so far.
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.
Greetings
     Janosch

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