I think the more important thing is the protocol itself, rather than the specific implementation. As the author notes the current D-bus standards are substandard at best.
I just see a bunch of undocumented C++ code here.
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
- 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.
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.
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)
He didn't barge in guns blazing proclaiming "pip is a disgrace" and "it's a fuckin joke". He wrote a tool that was much better and encourage others to try it. Within a year or so, it snowballed into an unstoppable change.
This project currently has a bunch of C++ files, no docs, no tests, no roadmap on how it might replace d-bus, nothing. And as another commenter pointed out, starting a new system service in 2025, yelling about security, and doing this in an unsafe language doesn't inspire confidence.
Lennart Poettering, Theo de Raadt and Linus Torvalds may get away with talking like this, but if you seriosly want to bring a wide community on board (without which the entire thing is a non-starter), look to Charlie instead.
Oh, and also, if you think D-Bus is bad, consider yourself lucky you didn't need to use the thing it replaced - CORBA.