D-Bus is the CORBA of IPC.
Actually, CORBA probably had better generators 🤔
@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.
@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 @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.
@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.
TCP is IPC
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
@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.
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!