Open jacobperron opened 5 years ago
gbiggs
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago After an offline discussion, I've updated this PR attempting to address the problem of identifying interfaces in general (pure IDL).
jacobperron
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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:
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
Follow up from https://github.com/ros2/rmw_opensplice/pull/263#discussion_r267590563
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.