Re: RTT-Introspection and how to do it ?

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

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.

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").

(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.)

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.

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