D-Bus is the CORBA of IPC.

Actually, CORBA probably had better generators 🤔


Arguably yes, but not typically used for what we consider (local) IPC. But as I see from your other response, you probably understand what triggered my post.

@fribbledom I haven't found anything fundamentally wrong with OORPC; it can work very well if the marshalling/proxying is reliable, convenient, efficient etc. and the API structures based on it are carefully designed. D-Bus and CORBA are both... disappointing.

@alexbuzzbee @fribbledom the problem seems to come from assuming over the network should work just the same as a local call and shouldn’t account for latency, turbulence or failure

@zens @fribbledom Remote RPC is janky in general because it's too implicit. Network communication needs error handling that the RPC model makes tricky. So I'll cut my position back to saying that OORPC is good locally, and in reliable conditions (good LANs), but not over the Internet or other unreliable networks without some modifications.

@alexbuzzbee @fribbledom all networks are unreliable. I have never seen a reliable LAN. But, even if in theory a LAN is great most of the time you don’t want your business critical software to just freeze on failure, ehich *will* eventually happen. you want sctual error messages. you want to be able to close the frozen application without causing cascading failures.

@zens @fribbledom Freezing on failure isn't acceptable even for local IPC. Even if a local process locks or crashes, the failure shouldn't cascade any further than it absolutely has to. So any RPC worth its salt has to have timeouts and some kind of reasonable error handling. My position is shifting as we go through this discussion, but error handling is definitely one of the key things that needs to be addressed well in designing RPC systems

@zens @fribbledom To reconsolidate what I think is a sensible position: OORPC can be a good model, but it must be able to handle and sensibly report transport and other-end failures. This is more important over networks, but always necessary and needs to be given careful consideration, as it can be quite tricky to do well. Convenient, reliable, and efficient marshalling/proxying and good API structures are other important factors for OORPC to be good.


@alexbuzzbee @zens @fribbledom Personally my attitude using DBus is: don't rely on those communication channels. Treat as optional enhancements.

Do rely on the X11/Wayland communication channels however, because if those fail something has gone disastrously wrong!

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).