[p_l]

- There's actual standard logic for remotely-existing objects vs. just RPC

- An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases)

- Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects)

- Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems)

That's just quick throw from memory.

[kentonv]

> - There's actual standard logic for remotely-existing objects vs. just RPC

Cap'n Proto is an object-capability system that very much has a uniform representation of remote objects. Object references are first-class types. You can send someone a remote object reference, embedded in some other message (e.g. params or return value of another RPC). When they release that reference, you get notified that the object can now be cleaned up.

Is there something else you were looking for here that Cap'n Proto doesn't do?

Not meaning to argue, just curious to understand. (I'm the author of Cap'n Proto.)

> - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases)

FWIW Cap'n Proto objects can implement multiple interfaces. That said, identity of remote objects is a surprisingly complicated subject, and at present it's not necessarily possible to tell whether two references point to the same object.

> - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects)

This is definitely a limitation of Cap'n Proto right now.

> - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems)

There is definitely a lot CORBA does here that Cap'n Proto doesn't. Cap'n Proto itself only defines object lifetimes within the context of an RPC session. Persistence and long-term object identity are left to a higher layer.

[p_l]

Was not aware that Cap'n Proto RPC got object references over network, need to update my knowledge some day (unfortunately for it, it's also not used by any project I need to interact with)

Persistence wasn't really an issue for me, though I am fully aware how popular in many ways it was to look there.

But ready made naming and discovery are somewhat important when:

- I don't want to mess with details of where specific endpoint is etc - with easily available open source CORBA code, I can setup single CORBA Naming service and provide reference to it from all other components, and while I could do it myself, there's a bit of ease to have a pre-existing IDL and basic "initial naming reference" I can utilise

- discovery is more the use of "Trader" service after establishing the naming part.

Essentially, I have few projects where I want to move the current hodge-podge of hard coded parts into a setup where components can be auto detected and auto configured dynamically with minimal effort from me, and with as wide language support as I can get (including Ada and Common Lisp)