Philipp Oppermann

> This genuinely takes an 1 hour to do on 10 robots, where it could have been instant with IP address and need to be done on every start. I...

Another possible alternative: Use zenoh for daemoncoordinator connection and rely on multicast messages for discovery. This would allow the daemon to send some kind of register message to whole local...

> It is simply impossible for me to see this being consistently reliable, while we could have just: > > * dora daemon connect to other daemon using direct address....

Let's maybe take a step back. One of our initial design goals was that the dataflows could be controlled from computers that are not part of the dataflow. For example,...

I feel like there is a lot of valid points and important things in this issue thread, but it's becoming difficult to follow. I think it would be a good...

We're still at 0.3.4, so we treat minor version bumps as breaking changes (e.g. 0.3.4 -> 0.4.0). So I assume that you mean patch version bumps (e.g. 0.3.4 -> 0.3.5)?...

Then we need some kind of separate versioning as I proposed above. We need some way to figure out whether nodes/daemons/coordinator are compatible before trying to parse the messages.

I think that's a good policy, but I'm not sure if we want to implement this just yet. We might still require some breaking changes to the message format in...

Some relevant places in the code: - https://github.com/dora-rs/dora/blob/60e4d7dd414e7ac8b962fd98159ba19f92a71343/libraries/core/src/topics.rs#L19-L21 - The CLI sets this directory on `dora start` when in sends the start command to the coordinator. The coordinator forwards it...

> If we pass parameter working_dir when we start daemon then we can manage working_dir just like machine_id, When a node is started, the coordinator passes the working_dir of the...