Global Message Subscription (akin to ROS)

[NiklasNeugebauer]

We have had an internal discussion about the benefits of offering a global system for publishing and subscribing to messages.
This GitHub Issue is meant to document the results of that discussion and facilitate it further.
None of the features are currently planned to be implemented.

Current State

Right now, rosys offers event channels through rosys.event.Event.
An event can be emitted and subscribed to directly through the event object.

Potential Issues with the Current State

The need to have direct access to the object might make the code less modular and flexible since every subscriber must have a reference to the object.
If events from multiple sources need to be handled by the same handler, they need to all be explicitly subscribed to.
Similarly, if new publishers may be created at runtime, they must be subscribed to each time.
Furthermore, access to the object requires access to the same memory, which might not be available in a multi-processing or even multi-machine setup.

Proposed Changes

The proposal is to expand the current functionality by allowing events to be emitted and subscribed to through some abstract reference.
Examples for such a reference include:

• a string, such as "image"
• a data signature, such as 'tuple[Image, str]'

This reference would be saved globally by the event class and could then be published or subscribed to by anyone.
The abstraction could also allow subscribing to multiple publishers at once even if subscribers are not available from the start.

Current alternative Solutions

The issue of collecting and adding multiple publishers is solved by the CameraProvider class and its child classes.
A CameraProvider manages multiple cameras and publishes all images through its NEW_IMAGE event.
Each time a camera is added, CameraProvider subscribes to camera.NEW_IMAGE with self.NEW_IMAGE.emit.

ROS

The discussed functionality was inspired by the major feature of ROS topics. ROS calls its references topics and manages the distribution of messages on topics through IP sockets which are established through the ROS Master process. One criticism of this ip-based mechanism is its overhead per packet leading to siginificant performance problems when handling a large number of messages.

[rodja]

The need to have direct access to the object might make the code less modular and flexible since every subscriber must have a reference to the object.

I would argue that the current system enforces clear dependency management where you can easily see what each module needs and processes. When we started with RoSys we had a world where all objects (and events) could be accessed by anyone. Removing this and making dependencies explicit was a great breakthrough and improved the readability/discoverability a lot.

If events from multiple sources need to be handled by the same handler, they need to all be explicitly subscribed to.
Similarly, if new publishers may be created at runtime, they must be subscribed to each time.

True. Do we have an example where this is problematic and how it would improve with a global message subscription?

Furthermore, access to the object requires access to the same memory, which might not be available in a multi-processing or even multi-machine setup.

I would like to not mix these topics. RoSys is based on NiceGUI/FastAPI/Starlette/Asyncio and by design uses a single process with event loop concurrency. That makes most coding very easy because you do not have to care about thread-safety and get linear readable code etc. If multiprocessing, threading or network communication is necessary the modules should encapsulate and hide this with Python and web technologies.

The discussed functionality was inspired by the major feature of ROS topics.

ROS needs to do this because it is inherently a micro service architecture. I think one of RoSys great advantages is the shared memory where a lot of this infrastructure is not required. If beneficial developers could simply launch RoSys as a ROS node to gain access to such features.