The loose federation of packages is actually one of my biggest problems with ROS. Once you get past the initial installation and poking around Rviz, Gazebo, and Turtlebot simulator, figuring out what to use ROS for requires a relatively tribal knowledge of different packages. When building software for a robot, there's a good chance that ROS has a solution either implemented or in-progress, but finding that solution may take just as much time and effort as building it yourself.
Ok, let me backtrack on why I want to poke around the ros core code.
After reading through ROS tutorials a few times, and after working on microservice architecture at my job for a couple years now, I'm starting to realize that ROS seems, at its core, a collection of microservices that utilize a message queue for communication between them. With that being said, there seems to be no reason why ROS has to be 1 - so closely tied to Ubuntu, and 2 - so closely tied to C++ and/or Python. So I want to poke around the roscore code, as in literally, all the code dependencies that are attached to what happens when I type "roscore" in the terminal. I want to understand more about the communication process, if the underlying technology is a queueing system, like MQTT, RabbitMQ, or Kafka, and what is the communication payload - XML, JSON, plain binary, or something else entirely.
I want to do this because before ROS finally started clicking with me, I was building a distributed robotics architecture on my robots using dockerized microservices written in Node, Scala, Java, and Groovy that communicated via REST and websockets, and started experimenting with integrating a message queue using RabbitMQ before I realized that I may be doing something similar to the underlying architecture of ROS.
So after writing this, it sounds like ros_comm is where I want to start. Does that sound right?
Thanks,
Luke