The adapter has some knowledge of specific message/srv types

[mwamp]

AFAIU some JS messages files are generated at build time. These will depend on the build environment at the time node-gyp is run. Calls to custom messages and services will raise errors if they were not present at build time - or won't they?- I got an error (something like fs: file not found) but maybe I did it wrong?)

This IMO is not typical ROS behavior. We want to be able to build code independently and then compose. In python project I can import my_msgs.msg without a care as long as there are references to it in my environment at run-time. And I don't have to rebuild rclpy.

I believe the purpose of the adapters is to give a unified ROS feel regardless of the language so I find this is rather important albeit maybe more time consuming to implement.

somewhat related : #356

[minggangw]

This IMO is not typical ROS behavior. We want to be able to build code independently and then compose. In python project I can import my_msgs.msg without a care as long as there are references to it in my environment at run-time. And I don't have to rebuild rclpy.

I believe you have to build for your own messages to generate the python bindings for your messages before starting your app. So during the runtime, you will not care about it.

The rclnodejs generates the JavaScript files at runtime instead as you said. Considering that the binding generation is triggered manually for Python, but the rclnodejs will not know the event that you have added new .msg. Here is a tricky solution:

• you can delete the folder generated/, so all messages will be re-generated including your own message.
• you can enforce the generation action. e.g. https://github.com/RobotWebTools/rclnodejs/blob/develop/index.js#L141

Indeed, it is not a good experience, but somehow we have to do it either before runtime or during.

[mwamp]

Considering that the binding generation is triggered manually for Python

I don't really get what that means but I get that cpp headers and "python header" are generated by idl when the packages srv/msg packages are built by colcon so maybe we can't achieve the same level of integration.

A few answers :

1. e8b0965 demonstrates how to add a loopback which will generate new message templates as long a there is a matching package in the ROS path.
   A caveat (among others probably) is that there is a risk to accumulate garbage in the generated files.

2. Is there actually any merit to these generated files? Could "generator" (actually keeping idl_generator or idl_adapter all the way might be more explicit) actually be completely dynamic? I wouldn't expect any significant performance issue.

3. I don't think there is a need to load these "before runtime". IMO it is completely acceptable to have the loader do it's job while the ros node is running and to choose a greedy/lazy load policy. Contrary to the concern of Use postinstall to generate the JavaScript messages #356 we don't necessarily need to wait for everyone to be ready to start serving pizza. Who cares if the pasta is not yet ready?

4. As it is this generator seems to be an inbetween, half of it could fit in a colcon_js package and the other part is a bookeeper useful to rclnodejs. (this is more a remark than a question)

[minggangw]

My description was a little obscure, I mean the process of generating the bindings for Python from idl files (.msg/.srv).

We can achieve the result that searching the unknown messages in the current ROS env variable and
generating dynamically in the run-time, which needs some changes to the generator in rclnodejs.