D-Bus Versus Varlink

[Lawrence D'Oliveiro]

I recently discovered the existence of Varlink <https://varlink.org/>.
Turns out it’s been around for a few years--here
<https://lwn.net/Articles/742675/> is some discussion of a rationale for
its creation. Note this bit:

    ... 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.

Commonalities with D-Bus:
* the concept of an “interface”, uniquely named according to the common
  reverse-domain format; which (among other things) defines named
  “methods”, each of which takes zero or more arguments
  (“in-parameters”) of specified types, and returns zero or more
  results (“out-parameters”) of specified types.
* A standardized introspection interface, that can be used to query a
  connection peer as to what interfaces it supports, and how they are
  defined.

Differences from D-Bus:
* No concept of an object path as the target of a method call. Hence no
  standardized interfaces for managing such objects, no get/set
  properties etc.
* No “signals” as such; however, method calls can return no reply, or
  even multiple replies. They can also return an “error” message
  indicating something went wrong with the method call.
* Point-to-point protocol, no intermediary daemon. So a client has to
  know the address (Unix socket, TCP etc) to connect to.
* Messages are JSON structs with standardized top-level fields;
  messages are terminated by a null byte.
* Struct field/argument types may be marked as “optional”, which means
  that the value is allowed to be null.
* Allows user-defined enumeration types, with specified strings as
  values.
* Allows user-defined names for enumeration and struct types.
* Defines its own introspection language, not based on XML (or JSON,
  or anything else immediately recognizable.)

(Anything else I missed?)

Note that a struct definition has exactly the same syntax as the
argument lists for methods and errors. Interesting that, instead of
C-style “«type» «name»” ordering for field/argument definitions, they
opted for Pascal-style “«name» : «type»” syntax. Named types are also
defined as “type «name» «definition»”, not as C would have it “typedef
«definition» «name»”.