Migrate communication libraries to control libraries

[domire8]

The name of the repo and corresponding docker images is network-interfaces. However, now the only library that it builds and contains is communication_library. Should we rename this repo and docker image or what do we do here @eeberhard @LouisBrunner ?

[LouisBrunner]

Maybe there will be other libraries in the future relating to network-related code that can be added here?

But if we consider renaming, I think we should consolidate control-libraries, modulo and/or this repo.

[eeberhard]

The initial idea for the repo was to consolidate general network-related code beyond sockets (including serial other device IO). So, renaming is not really a priority in my opinion.

But honestly, adding communication_interfaces to control-libraries is not a bad idea at all. It If the control libraries image contains all library binaries and dependencies, it would be very easy to include whichever parts are needed downstream. The fact that communication_interfaces doesn't depend on state representation is definitely a bonus for simplicity, but whenever we do want to send and receive encoded state messages, the two libraries would be available in the same image. With cmake, the library versions can also be managed independently. The only thing to track would be that CL image v7.2 contains comms library v1.0 or whatever.

It can also be a part of control-libraries but retain a standalone, separately versioned image out if that's cleaner.

we should consolidate control-libraries, modulo

This one I don't agree with, because the intention is to keep one ROS agnostic, while the other (modulo) is ROS-centric.

[domire8]

Okay, so considering your answers, we leave the repo like that, good for me. I will tag a new version right after I delete develop.

However, moving communication_libraries to control libraries sounds like a whole lot of work without a lot of benefits. It can be put on the backlog but I don't feel like actioning it right away. Is that okay?

[eeberhard]

yes no priority on a migration. Like Louis implied, rather not make the "half-way" effort of renaming the repo and updating downstream users if there is a better long-term fit. You can rename this issue and keep it as a backlog item, so that the next time a refactor or feature comes in around this library or repo, we can consider redeploying to control-libraries

[domire8]

Should we bring this back to the table since we are refactoring CL anyway in aica-technology/control-libraries#159? An 8.0.0 is almost unavoidable, especially with aica-technology/control-libraries#163