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 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.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.