D-Bus is the CORBA of IPC.

Actually, CORBA probably had better generators 🤔

· · Web · 5 · 5 · 14

@fribbledom D-Bus and CORBA are actually quite similar when you boil them down. They're both OORPC. Intended for very different purposes, and different in almost every particular, but fundamentally similar.


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.

Joke (ish?) 

Ethernet is IPC
Putting files on a drive and mailing it is IPC
Every way of moving digital information is IPC and no one can possibly ever prove me wrong

Joke (ish?) 

@cinebox @fribbledom The clipboard is absolutely IPC, just user-controlled IPC.

@fribbledom Yet another hill I will die on: CORBA is not the shit technology that everyone made it out to be.

CORBA is one of my favorite technologies.

@vertigo @fribbledom The best programmer I personally know put it roughly like this, "If you intend to actually solve all the problems CORBA addresses, it's really not much, or anything, you can remove." The last years I've been annoyed by a library at work created by a guy who felt OSGi was too big and bloated, so he implemented a subset. That library... so much would have been easier, more efficient, more maintainable, etc, etc if he simply used OSGi.

@fribbledom DBus was made to be a lighter simpler CORBA. GNOME hat ORBit which was its own CORBA implementation but wanted something a lot lighter. Thus DBus was created.

@rysiek @fribbledom oh, good, because if you lie on one of the cables the data can't get through.

@rysiek @fribbledom have to believe eventually this thread will become consistent.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!