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!

@alexbuzzbee @fribbledom when I said “local” i mean CORBA and alikes (SOAP, OLE) try to make IPC look like in process function/method calls, synchronous and all. once something is a synchronous call it’s much harder to have something even as simple as a timeout. exceptions aren’t reliably cross language so it needs to be return codes that you check and return. it starts looking less and less in process.

@alexbuzzbee @fribbledom the “opposite” approach seems more successful; treat even in process calls as ipc with potential for failure. you see this in erlang. (so i have read)

@alexbuzzbee @fribbledom and increasingly in yawascript with async/await and promises. apie that used to be synchronous often become async with potential for failure after it becomes clear that it is needed

@zens @fribbledom What I would do in e.g. Rust is make every method on a maybe-RPC thing return a Result with a fairly wide-open error type, even methods that have no nominal failure conditions. Then the RPC infrastructure can tie in there to report timeouts and other RPC-only failures. In a language with exceptions I would simply throw. In e.g. C I would make everything return an error and put the result in a pointer. These models are, I think, reasonably compatible.

@zens @fribbledom To do error handling well you do have to constrain allowed API structures to ones that permit reporting of RPC problems; this works better in some languages than others, but I think it can be made to work well across most procedural languages.

@zens @fribbledom Basically: With RPC, anything can fail. Plan appropriately. If you plan well, this isn't much of an inconvenience, but you do have to plan well.

@zens @alexbuzzbee @fribbledom DBus btw has exceptions. I don't know all the different language bindings, but Vala's at least requires every method to declare it can throw I/O errors.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.