Update ROS node graph API

[jacobperron]

The node function get_topic_names_and_types() now returns a vector for each type name
containing the parts of the fully qualified name.

Connects to ros2/ros2#677

[wjwwood]

Personally, I think this is a step backwards for the user facing API, because it makes it harder to consume when you care about the whole type and requires the user to manually concatenate the parts. Would it not be better to leave this API as-is and then provide a new API that gives it in parts, e.g. get_topic_names_and_split_types()?

[wjwwood]

Another name might be get_topic_names_and_type_tuples(). Also, why is the type a vector rather than a tuple or array? The number of elements doesn't change does it?

[jacobperron]

Personally, I think this is a step backwards for the user facing API, because it makes it harder to consume when you care about the whole type and requires the user to manually concatenate the parts

Yeah, I was kind of feeling the same as I was writing this. I was just propagating the change from rmw (ros2/rmw#170).

Would it not be better to leave this API as-is and then provide a new API that gives it in parts

This sounds like a better option. Still, the idea was to remove possible ambiguity from the type name (see ros2/design#220 and ros2/rmw_opensplice#263 (comment)) and so the concatenated string would be "pkg_name/namespace/TypeName". But I believe rviz is still expecting the form "pkg_name/TypeName"?

Also, why is the type a vector rather than a tuple or array? The number of elements doesn't change does it?

In the current IDL pipeline, I don't think it's possible for there to be more than three elements (I might be wrong). But I was proposing that there could be any number of parts to the namespace in ros2/design#220. This can still be discussed there and changed accordingly.
Edit: it could certainly be an array.

[wjwwood]

so the concatenated string would be "pkg_name/namespace/TypeName".

That would be fine for me.

But I believe rviz is still expecting the form "pkg_name/TypeName"?

That's possible, but I'd prefer to see us move towards the new style (pkg_name/msg/TypeName), and then let rviz allow for plugin descriptions to still use pkg_name/TypeName by implicitly inserting msg/ after the first /, perhaps making a deprecation warning at the same time.

In the current IDL pipeline, I don't think it's possible for there to be more than three elements (I might be wrong). But I was proposing that there could be any number of parts to the namespace in ros2/design#220. This can still be discussed there and changed accordingly.
Edit: it could certainly be an array.

I was just curious about this, if it needs to be a vector that's ok by me.

[jacobperron]

Decided to keep the type as a / delimited string rather than returning a nested list to keep the API simpler.

I'm not sure what (if anything) needs to be done to handle cases when more than two parts are returned (ie. pkg_name/msg/TypeName).

[jacobperron]

Ready for review.

I've updated all of the default plugins to declare the type's full namespace (e.g. sensor_msgs/msg/Image).
To provide maintainers for thirdparty plugins a chance to update, we assume that they intended to include the msg part of the namespace and log a warning.

[jacobperron]

• Linux
• Linux-aarch64
• macOS
• Windows

[jacobperron]

I don't know why the macOS is showing unstable. There are no test failures, but some warnings produced when running the tests. The warnings are also on Linux, but it is green. I also checked locally that the warnings existed prior to the change introduced in this PR.

[wjwwood]

@jacobperron if you have a moment can you add a note to https://index.ros.org/doc/ros2/Releases/Release-Dashing-Diademata/#changes-since-the-crystal-release about the need for plugins to update their plugin descriptions, otherwise they get a warning?