commented:

consistency: the wire itself enforces types and message arguments. No
"a{sv}", no "just send something lol"

So the argument here is that the wire enforces arguments, unlike
a{sv}, which is... a type encoded into the wire protocol? But of
course nobody would ever want "complicated struct types".

Any app can register secrets, which only it can read back. Secrets
cannot be enumerated. This means that when "/usr/bin/firefox" sets a
"passwords:superwebsite.com = animebooba", an app called
"~/Downloads/totally_legit.sh" can not see the value, or the key, or
that firefox even set anything.

How are you going to enforce this?

  commented:
Varlink is worth bringing up here as an existing alternative based on
Unix domain sockets, well-known filenames, & JSON.

  commented:
As is Binder, as used in Android.

  commented:
I'm not sure Varlink is any better. Some of the issues I ran into in
the past when working with it (I was using the systemd-resolved
varlink API):

It's null terminated JSON instead of just regular JSON. I guess just
JSON made too much sense?
You can request the schema through some opaque command, but the output
is essentially just an undocumented dump of a bunch of types. I found
this to be super useless
Documentation in general was a disaster
It's just as insecure as dbus: if you have access to the Unix socket,
you have access to everything provided by the service
Outside of systemd-resolved and maybe a few other systemd services, I
don't remember seeing it used anywhere else


  commented:
If you're sending multiple JSON payloads, NUL is actually an easier
terminator to work with than newlines because it's not legal in a JSON
message. I've definitely seen it before.

  commented:
I can’t really speak for now, but I do remember it becoming a standard
part of distros and it making a bunch of standard things much better
than the status quo of the time. I wish I could remember what any of
those things were :)
Anyway, from reading the article most of this seems to be
implementation issues rather than the concept - certainly it’s bizarre
that DBUS does not enforce any kind of access restrictions, but that
might simply be due to the lack of any kind of entitlement style
mechanism on Linux, and the inability to validate those entitlements
(seriously codesigning is valuable).
That other “apps don’t follow the rules” seems like a classic hyrums
rule issue that falls out of be permissive in what you accept: any new
software should be strict as failing to do so exacerbates this.
Obviously DBUS can’t change but newer bus services should not repeat
the mistakes of the past.

  commented:

I wish I could remember what any of those things were :)

In KDE, it replaced DCOP.

  commented:
And for gnome it was bonobo iirc. Both were inspired by corba.
Although dbus is only the message broker part afaiu

  commented:
Comment removed by author
  commented:
Interesting! Let's see where this goes!
.