param /vs/ services /vs/ topic : Pyzmp communication concepts

[asmodehn]

ROS has 3 was to communicate :

• param (global state)
• topic (pub/sub : one way communication, data changing overtime)
• service (two way communication, idempotent/pure function design, ie for a fixed status, response is assumed fixed and consumed automatically)

Other systems have a combination of these. (REST is services only, but often a DB back is added and provide a global-state, at least for the backend side, MQTT is topics only, and topics can be used to implement services, etc.)

It could be interesting for pyzmp to unify these concepts, ie. design one communication concept that can be used to implement all of them (since each seems to be a specialization of a more abstract/basic concept).

Services are very versatile to handle communication (discoverable, client needs no specific requirements, etc.), and are already implemented, so it make sense we use these as a base.

We need to add :

• multiple response overtime -> the service then behaves as "setting up a hook". This has to be the generic way of using the service. Receiving only one response, or signaling that all responses later will be the same, is a special case. We probably need a future as a response, plus some queue manipulation to consume responses... Maybe also a way to inverse controlflow...

• multiple request overtime -> a service can already do that by sending many requests, and not expecting any answer. But we need a way in code to express that we dont need any answer. So implementing async call should be enough.

• global state -> a service should be used to maintain the visibility of a global state for the pyzmp multiple processes. likely implementing raft.

[asmodehn]

More thinking about this topic :

• We should definitely have only ONE concept for communicating. Service is the main usecase for this concept, but it s a specific way of using it. Most (all?) concurrent computing theories have only one, so it should be enough.
• We should try to stick to concepts that are backed up by theory (CTL*, process calculi, etc.) if possible. unless someone has time to develop another theory?
• I personally like the thinking behind Reo especially the Exogeneity. So maybe the communication pattern should not be in code, but "outside" of it (thinking of python decorators... ?)
• We should merge both direct and inverted control flow... and probably also concurrent execution from composition (one call can generate multiple responses delayed in time...). we should check multiple theories and find the ones that match these requirements...

[asmodehn]

We need to dive more into https://docs.python.org/3/library/asyncio-task.html
It seems a coroutine (or mixing a future with a generator) could give us the functionality we need of a function that can be called once and return a value multiple times, at different intervals...