Atm the StrategyNode allows you to treat it as a node and behind the scene you get the speed of a daemon or a direct node (with potential discovery delays). For the referenced issue I think we want a node which uses daemon methods when available and otherwise use the methods on a direct node. Maybe that kind of functionality shouldn't go into StrategyNode but into a new class since it is a pretty different usage / expected API?

Such a new class would provide the exact same functionality that NodeStrategy provides for all existing use cases, plus

a node which uses daemon methods when available and otherwise use the methods on a direct node.

Considering that this patch is almost completely transparent[1] for all uses cases that rely on the current NodeStrategy behavior, I don't see the point in creating yet another class. I can imagine NodeStrategy being progressively replaced by it over time.

[1] There's one difference: if a direct node gets instantiated on method call, it'll have been alive for a shorter amount of time than with the current implementation. That, nonetheless, should not be a problem since most if not all discovery sensitive API is provided by the daemon.

Is the goal here to address #488?

Can you still answer this question?

Is the goal here to address #488?

This PR sets up the scene. I'll update #494 to make use of these features, which will ultimately address #488.

CI up to ros2cli:

• Linux
• Linux-aarch64
• macOS
• Windows

Alright, this one's ready to go. How you feel about it @jacobperron ? It doesn't change API, but it affects most ros2 CLI verbs.

IIUC, we're affecting most CLI verbs for the better, so I'm okay with this (and the connected PR) landing for the Foxy release candidate.

Alright, going in!