5 ms·

It would be interesting to see a IPC system that abstracted away where the other process was running or treated processes running on an entirely different machi

It would be interesting to see a IPC system that abstracted away where the other process was running or treated processes running on an entirely different machine or VM as another local process. Since scalability is probably a bigger concern in web architectures than robotics, expecting to be able to use IPC to communicate between two services is unlikely. I would imagine in many web architectures being able to scale systems independently and dynamically makes up for the overhead in communication protocols.

osullivj 9y ago
You can get this kind of decoupling from a pub sub msg bus. And async too. Much better than point to point HTTP.
- Animats 9y ago
  ROS is pub/sub, but that works because most of the data traffic is one way, sensor->compute->actuator. ROS isn't usually used for function call type operations. If nobody's listening to a sensor, that doesn't hurt the sensor any.
badosu 9y ago
> It would be interesting to see a IPC system that abstracted away where the other process was running or treated processes running on an entirely different machine or VM as another local process. Erlang processes do this if I'm not mistaken.
- mml 9y ago
  Erlang does do this. In fact, it dawned on me that OTP is basically a system for writing "micro services" inside the app itself, complete w/ monitoring, queues (mailboxes) & supervision. Developers are forced to export public module functions to provide a smooth api for other services (processes, in the same runtime, or distributed). Thankfully, Erlang provides the protocols and so on, instead of requiring some nasty hand-crafted json weirdness over http.
spc476 9y ago
This was attempted back in the late 80s/early 90s with RPC (from Sun) and CORBA (not sure who is responsible for that monstrosity). This time around it's what ... 0MQ and Protobufs?
Chaebixi 9y ago
> It would be interesting to see a IPC system that abstracted away where the other process was running or treated processes running on an entirely different machine or VM as another local process. Forcing everything into the same abstraction can have issues. For instance, calling a different machine has orders of magnitude more overhead and different error scenarios than making a call to a local process. If you make them look identical, you obscure that.

osullivj 9y ago

You can get this kind of decoupling from a pub sub msg bus. And async too. Much better than point to point HTTP.

Animats 9y ago
ROS is pub/sub, but that works because most of the data traffic is one way, sensor->compute->actuator. ROS isn't usually used for function call type operations. If nobody's listening to a sensor, that doesn't hurt the sensor any.

badosu 9y ago

mml 9y ago
Erlang does do this. In fact, it dawned on me that OTP is basically a system for writing "micro services" inside the app itself, complete w/ monitoring, queues (mailboxes) & supervision. Developers are forced to export public module functions to provide a smooth api for other services (processes, in the same runtime, or distributed). Thankfully, Erlang provides the protocols and so on, instead of requiring some nasty hand-crafted json weirdness over http.

spc476 9y ago

This was attempted back in the late 80s/early 90s with RPC (from Sun) and CORBA (not sure who is responsible for that monstrosity). This time around it's what ... 0MQ and Protobufs?

Chaebixi 9y ago

> It would be interesting to see a IPC system that abstracted away where the other process was running or treated processes running on an entirely different machine or VM as another local process. Forcing everything into the same abstraction can have issues. For instance, calling a different machine has orders of magnitude more overhead and different error scenarios than making a call to a local process. If you make them look identical, you obscure that.