That looks good to me, especially passing the node handle to avoid needing any GUID’s or anything like that.
I do have a few things to point out however:
I’m somewhat concerned about the performance of the API design. As you said, it allows you to avoid any new or complicated data structures by calling these functions once for each node and entity type. However, two cases are less efficient: “listing all topics (publishers or subscribers), or services, for all nodes, by node” and “listing all topics and services on a given node”. Both require multiple calls to the API, but mostly the former case may require many calls if there are many nodes.
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.
My other concern is related to the association of publishers to nodes. In the
rmw_take_with_info call you can get the GUID of the publisher which sent the data (caller id), but that doesn’t necessarily let me figure out which node it came from (unless it was my own node and I have a handle to the publish that sent it). So I was hoping to eventually get not just the name and type of the remote publishers but also the GUID.
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).
So like I said, I think this proposed API makes sense and is a good first step to tackle this issue.
If you want we can setup a short video call to hash out any other issues/questions you have and then post the result here on discourse.