We discussed allowing to create a rclcpp::TimerBase from a rcl_timer_t object but that’s not easy to do (we need a way to extract clock and context shared pointers from the rcl layer) and probably not the correct approach.
Proposal: we may want to have a policy where rcl never creates entities on its own, but they are always created via the rclcpp/rclpy layers. This ensures that they can easily be accessed.
Question: this PR introduces an API named rcl_action_server_init2. There are precedents for calling new APIs like this (e.g. rcl_init_timer2), is this a practice we should recommend?
Discussed a bug: creating clocks via their constructor, rahter than via a ROS node, will not connect them to a ROS source, so they won’t follow the ROS time. This can be a source of hard to debug problems. We still should allow to create MONOTONIC or SYSTEM clocks without a node.
This PR simplifies how “wait until” is managed for different types of clocks, even if there’s some code duplication.
We should deprecate the Clock::cancel_sleep_or_wait API. This was introduced in Jazzy right before the code freeze. Likely no one is using it and it’s broken.
How to avoid this type of issues? We could anticipate the code freeze, or we could leverage more features like the “experimental” namespace. We have to be careful to not discourage contributors or just delay the problem.
Question: if we break API/ABI for a class in the experimental namespace, are we affecting people that are using rclcpp but are not using this class?