ROS graph information tools implementation discussion

[ross_2]

@wjwwood

That all being said, I’m not very concerned about it since I don’t think performance will be a must-have in those cases (mostly for tools). And we can always add new API’s later that make this more efficient.

I completely agree, I was thinking of exposing an unzipped data structure containing lists ordered in such a way the rcl user could cache what they need. However there is no partial implementation of that interface should the RMW implementation be unable to access certain data. We can add bulk implementations should we need it going forward and address this issue.

@wjwwood

This is definitely not a blocker for this work, but it’s something to consider, since you might not even have the proposed signatures if you could get publisher by GUID (and therefore maybe create a struct that serves as a proxy for remote publishers which encapsulates information like GUID, node GUID, topic name, and type).

This is true, and will be extremely interesting when we attempt to inspect a working system message by message. This API is meant for node graph tools that simple show connectivity, not on a per message basis.

Let’s set up a call and hammer out this API to get some node graph tools up and running.