Remove name mangling of .idl files for compatibility with non-ROS2 dds nodes

[jespersmith]

Feature request

Currently, using .idl still results in name mangling of the data type. A struct name "module::msg::struct" becomes "module::msg::dds_::struct_". This breaks easy compatibility with non-ROS2 DDS implementations. Ideally, no name mangling is done.

Alternative, allowing to declare a name-mangled version allows transition to existing DDS implementations without rewriting the .idl file.

module module 
{
module msg
{
module dds_
{
struct struct_

};
};
};
};

Feature description

This feature would allow easy integration with existing DDS implementations.

Implementation considerations

Removing name mangling will break backwards compatibility.

Allowing to specify the mangled name will make the .idl ugly, but not break anything outside the .idl.

[dirk-thomas]

The name mangling does exist for a reason. Without it the generated ROS type and the generated DDS type would conflict with each other and therefore not be usable at the same time in e.g. C++. In order to create instances of each type in a single compilation unit and convert the data from one type to the other the type names must be different.

Any proposal how to improve the situation would be highly appreciated.

[jespersmith]

To clarify, I would prefer that the topic data type on the wire is set matching the .idl name, and not mangled to match the ROS2 naming, so non-ROS2 subscribers/publishers can use the same .idl definition to talk to ROS2 nodes.

With FastRTPS, you set the data type when creating the topic parameters (Wparam.topic.topicDataType = "[Topic type]"). You could override the data type to match the .idl instead of the ROS2 mangled name. That way, conflicts between data types are avoided but the name on the RTPS protocol matches what is expected from the original .idl.

I'm not sure if this is possible with Opensplice/RTI Connext however. Also, this would break backwards compatibility for communicating with previous ROS2 releases.

[calvertdw]

I haven't looked too much into this, but what about combining the generated ROS type and the DDS type. I assume they are two separate C++ objects in this case? Could you make a super interface?

[dirk-thomas]

I assume they are two separate C++ objects in this case? Could you make a super interface?

I can't imagine what this should look like. Please describe your idea in more detail.

[Aposhian]

Something that adds to the confusion is the the ".idl" output by rosidl_adapter is not compatible with the actual idl that is needed to generate a compatible interface on the wire. If the ".idl" files need to exist in the "ROS format" for specific reasons, then maybe they should have a different extension like ".rosidl", because you can't just run it through and IDL compiler for one of the DDS implementations have it be compatible with what ROS actually uses.