Revision history [back]

You can either use existing data structures and associated type support or you can create new data structures and associated type support objects. Python, for example, just reuses the C data structures, so it doesn't need its own type support as well. However, the Python implementation could have, instead, generate its own version of data structures (maybe as PyObject's), but then every rmw implementation that doesn't use the introspection type support would need to generate code to handle these PyObject's.

At the core, three is a function that most type support objects have, which is to convert the user's data structure into something the middleware handle. So as an example, consider std_msgs/String. It generates a C data structure called std_msgs__msg__string but for Connext (as an example, because it has it's own type support) needed to publish this, we'd first need to convert it to a compatible type Connext could consume. That might be either a CDR buffer (uint8_t[]) or a DDS type generated from IDL like dds::std_msgs::msg::string (something like that). So a pair of functions to convert to and from these types would be stored in the opaque part of the type support. If you wanted to create yet different data structures you'd need matching type support for all supported rmw implementations.

The type supports are paired between the data structure type (C or C++ is all we have right now) and the implementation that needs to operate on those types. So for example, you can see here how Connext supports both C and C++ type supports:

• https://github.com/ros2/rmw_connext/tree/master/rosidl_typesupport_connext_c
  • https://github.com/ros2/rmw_connext/blob/master/rosidl_typesupport_connext_c/resource/msg__type_support_c.cpp.em
• https://github.com/ros2/rmw_connext/tree/master/rosidl_typesupport_connext_cpp
  • https://github.com/ros2/rmw_connext/blob/master/rosidl_typesupport_connext_cpp/resource/msg__type_support.cpp.em

In the future, once some technical details have been sorted out, it might be possible to simplify this interface so that we don't need rmw implementation specific type supports. This might be possible by instead making the interface only send/receive CDR serialization buffers which are untyped (uint8_t[]'s). But for now, we still need to convert directly to/from the user's in memory representation (whether that be a C, C++, or Ada data structure) to the equivalent DDS data structure for a given vendor.

There's also the "introspection" type support, which can be used by any rmw implementation that chooses to do so, and it works by operating on meta data about the message rather than having explicit conversion functions. It can be pairs with DDS's X-Types or used directly. This is what FastRTPS does right now. You can see it here for both C and C++:

• https://github.com/ros2/rosidl/tree/master/rosidl_typesupport_introspection_c
  • https://github.com/ros2/rosidl/blob/master/rosidl_typesupport_introspection_c/resource/msg__type_support.c.em
• https://github.com/ros2/rosidl/tree/master/rosidl_typesupport_introspection_cpp
  • https://github.com/ros2/rosidl/blob/master/rosidl_typesupport_introspection_cpp/resource/msg__type_support.cpp.em