Re: D-Bus Versus Varlink

Hi,

Interesting coincidence that I was just recently convinced by Lennart
about Varlink being better than D-Bus in many ways and could
potentially replace it in the future. You can follow the discussion
here and also participate: https://toot.cat/@zeenix/112118118300533277

> >     ... it aims to provide IPC from early boot onward, though it does
> >     not really address the longtime D-Bus performance complaints that
> >     also served as motivation for kdbus and bus1.

It does, actually. The main performance issue with D-Bus is all the
context switching required. With p2p connection, you remove a major
source of this latency: the bus. Granted you can also do p2p with
D-Bus but D-Bus was never really designed for that and you end up with
redundant headers etc and don't get some of the benefits of using
D-Bus.

While I was a bit skeptical about the claim that JSON
encoding/decoding is only a small fish compared to the effects of
context switching, my own benchmarks convinced me that to be true:
https://toot.cat/@zeenix/111971114434573026

> > * No “signals” as such; however, method calls can return no reply, or
> >   even multiple replies.

AFAICT those multiple replies are very much all you need. Some methods
can be thought of as a signal subscription.

 > > * Point-to-point protocol, no intermediary daemon. So a client has to
> >   know the address (Unix socket, TCP etc) to connect to.

* IMHO this is not very different from knowing the name of the service.
* There is a concept of a resolver: https://varlink.org/#resolver

-- 
Regards,

Zeeshan Ali Khan