REP-2016 type hashes now exist and are passed during discovery for the 3 DDS implementations, but are only exposed through rmw_topic_endpoint_info_t, which is given by get_publishers_info_by_topic/get_subscriptions_info_by_topic, but otherwise is not exposed.
When querying information about a node rather than a topic, one generally uses rmw_get_publisher_names_and_types_by_node(etc) which returns the topic name and typename, but does have access to the type hash, which it would be appropriate to return in these functions, making it easier to then query information about those topics.
Implementation considerations
This probably looks like:
typedef struct RMW_PUBLIC_TYPE rmw_names_and_types_s
{
/// Array of names
rcutils_string_array_t names;
/// Dynamic array of arrays of type names, with the same length as `names`
rcutils_string_array_t * types;
/// NEW FIELD
/// Dynamic array of type hashes, with the same length as `names`
rosidl_type_hash_t * type_hashes;
} rmw_names_and_types_t;
And then will require filling out this information in all names_and_types APIs.
This would be ABI-breaking, so probably can only be planned for Jazzy.
Feature request
Feature description
REP-2016 type hashes now exist and are passed during discovery for the 3 DDS implementations, but are only exposed through
rmw_topic_endpoint_info_t
, which is given byget_publishers_info_by_topic
/get_subscriptions_info_by_topic
, but otherwise is not exposed.When querying information about a node rather than a topic, one generally uses
rmw_get_publisher_names_and_types_by_node
(etc) which returns the topic name and typename, but does have access to the type hash, which it would be appropriate to return in these functions, making it easier to then query information about those topics.Implementation considerations
This probably looks like:
And then will require filling out this information in all
names_and_types
APIs.This would be ABI-breaking, so probably can only be planned for Jazzy.