A gold standard behaviour for when you want to replace a disfunctional tool/system and will require buy-in from a wide community, is to behave like Charlie Marsh did with ruff and uv.
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.
Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer."
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
> This project currently has a bunch of C++ files, no docs, no tests
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 think one of the point from your parent comment is that something that works for people is a powerful way of making things happen, much more powerful than rants or theory or protocols. I also noticed that with cryptography algorithms/protocol for example: design the most amazing algorithm - no one is going to use it ever if there is no great reference implementation people can use.
> - 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.
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)
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.