Add section on uniquely identifier interface definitions

[jacobperron]

Follow up from ros2/rmw_opensplice#263 (comment)

This is a proposal for uniquely identifying ROS interfaces that does not make any assumptions about the subfolder(s) where the interface definitions are found.

[gbiggs]

Can we do better than relying on file system layout to uniquely identify a message? What about using package name and a hash generated from the comment-less version of the message definition?

[dirk-thomas]

What about using package name and a hash generated from the comment-less version of the message definition?

That doesn't seem practical if the user has to specify a message type on the command line.

[gbiggs]

That doesn't seem practical if the user has to specify a message type on the command line.

True. I was thinking only in terms of automated tools, but the usability aspect for the user/programmer is probably more important.

[jacobperron]

After an offline discussion, I've updated this PR attempting to address the problem of identifying interfaces in general (pure IDL).

[dirk-thomas]

Considering a command line tool like ros2 msg I would expect it to take a URN as an argument. The problem I see is that it doesn't know what the correct URL is in order to import the module containing the type.

[jacobperron]

Considering a command line tool like ros2 msg I would expect it to take a URN as an argument. The problem I see is that it doesn't know what the correct URL is in order to import the module containing the type.

Is it possible for typesupport to provide the URL? I.e. provide a mapping from a types URN to the URL.

[dirk-thomas]

Is it possible for typesupport to provide the URL? I.e. provide a mapping from a types URN to the URL.

Maybe that information could be put into the resource index. Currently each URN has a marker file in the resource index. Instead of using an empty file it could contain the URL.

[jacobperron]

Maybe that information could be put into the resource index. Currently each URN has a marker file in the resource index. Instead of using an empty file it could contain the URL.

That might work. But is it the case that there is a marker file for each URN? It looks like there is a single marker file for the package containing relative paths to the resource files (not necessarily URNs). For example, there's a file install/test_msgs/share/ament_index/resource_index/rosidl_interfaces/test_msgs containing:

content

action/Fibonacci.action
action/Fibonacci.idl
action/NestedMessage.action
action/NestedMessage.idl
msg/BoundedArrayNested.idl
msg/BoundedArrayNested.msg
msg/BoundedArrayPrimitives.idl
msg/BoundedArrayPrimitives.msg
msg/BoundedArrayPrimitivesNested.idl
msg/BoundedArrayPrimitivesNested.msg
msg/Builtins.idl
msg/Builtins.msg
msg/DynamicArrayNested.idl
msg/DynamicArrayNested.msg
msg/DynamicArrayPrimitives.idl
msg/DynamicArrayPrimitives.msg
msg/DynamicArrayPrimitivesNested.idl
msg/DynamicArrayPrimitivesNested.msg
msg/DynamicArrayStaticArrayPrimitivesNested.idl
msg/DynamicArrayStaticArrayPrimitivesNested.msg
msg/Empty.idl
msg/Empty.msg
msg/Nested.idl
msg/Nested.msg
msg/Primitives.idl
msg/Primitives.msg
msg/StaticArrayNested.idl
msg/StaticArrayNested.msg
msg/StaticArrayPrimitives.idl
msg/StaticArrayPrimitives.msg
msg/StaticArrayPrimitivesNested.idl
msg/StaticArrayPrimitivesNested.msg
srv/Empty.idl
srv/Empty.srv
srv/Empty_Request.msg
srv/Empty_Response.msg
srv/Primitives.idl
srv/Primitives.srv
srv/Primitives_Request.msg
srv/Primitives_Response.msg