Use routes as `YAML` dictionary keys instead of `topics`/`services`

[mxgrey]

After spending some time writing files using the soss_v2 configuration format, I've realized there's a glaring source of redundancy: route specification. I have a proposal for an addition to the format. Here's an example using the current format:

routes:
  ros1_to_ros2: { from: ros1, to: ros2 }
  ros2_to_ros1: { from: ros2, to: ros1 }
  ros2_service: { server: ros2, clients: ros1 }

topics:
  topic_1: { type: my_package/MyType1, route: ros1_to_ros2 }
  topic_2: { type: my_package/MyType2, route: ros1_to_ros2 }
  # ... etc ...
  topic_8: { type: my_package/MyType8, route: ros2_to_ros1 }
  topic_9: { type: my_package/MyType9: route: ros2_to_ros1 }
  # ... etc ...

services:
  some_service_1: { type: my_package/MyService1, route: ros2_service }
  some_service_2: { type: my_package/MyService2, route: ros2_service }

We could instead allow:

routes:
  ros1_to_ros2: { from: ros1, to: ros2 }
  ros2_to_ros1: { from: ros2, to: ros1 }
  ros2_service: { server: ros2, clients: ros1 }

ros1_to_ros2:
  topic_1: { type: my_package/MyType1 }
  topic_2: { type: my_package/MyType2 }
  # ... etc ...

ros2_to_ros1:
  topic_8: { type: my_package/MyType8 }
  topic_9: { type: my_package/MyType9 }
  # ... etc ...

ros2_service:
  some_service_1: { type: my_package/MyService1 }
  some_service_2: { type: my_package/MyService2 }

This would save some typing, and I think it would make it more clear exactly how information is moving between the middlewares.

This could either be an addition to the existing format, or it could be a complete replacement depending on whether we should favor the "have only one way to do it" principle or whether we should favor flexibility. Personally I lean towards flexibility, but there are strong arguments to be made for the "have only one way to do it" camp.

[codebot]

I like it. Seems much more concise, which is a key part of legibility imho. As another way to reduce redundancy between config files we could also adopt a convention where routes named SYSTEM1_to_SYSTEM2 are always defined "implicitly". More routes could be defined if desired, but in many common/simple cases, they would not be needed.

…

On Wed, Jun 12, 2019, 5:55 PM Michael X. Grey ***@***.***> wrote: After spending some time writing files using the soss_v2 configuration format, I've realized there's a glaring source of redundancy: route specification. I have a proposal for an addition to the format. Here's an example using the current format: routes: ros1_to_ros2: { from: ros1, to: ros2 } ros2_to_ros1: { from: ros2, to: ros1 } ros2_service: { server: ros2, clients: ros1 } topics: topic_1: { type: my_package/MyType1, route: ros1_to_ros2 } topic_2: { type: my_package/MyType2, route: ros1_to_ros2 } # ... etc ... topic_8: { type: my_package/MyType8, route: ros2_to_ros1 } topic_9: { type: my_package/MyType9: route: ros2_to_ros1 } # ... etc ... We could instead allow: routes: ros1_to_ros2: { from: ros1, to: ros2 } ros2_to_ros1: { from: ros2, to: ros1 } ros1_to_ros2: topic_1: { type: my_package/MyType1 } topic_2: { type: my_package/MyType2 } # ... etc ... ros2_to_ros1: topic_8: { type: my_package/MyType8 } topic_9: { type: my_package/MyType9 } # ... etc ... This would save some typing, and I think it would make it more clear exactly how information is moving between the middlewares. This could either be an addition to the existing format, or it could be a complete replacement depending on whether we should favor the "have only one way to do it" principle or whether we should favor flexibility. Personally I lean towards flexibility, but there are strong arguments to be made for the "have only one way to do it" camp. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABIFDWRC7IGWEDPHHUWZGSLP2DBYDANCNFSM4HXHI3EQ> .