[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: D-Bus Versus Varlink
From:       "Thomas Kluyver" <thomas () kluyver ! me ! uk>
Date:       2024-03-21 12:58:54
Message-ID: d2c0246d-0153-4a04-b8a0-29518c08ff5b () app ! fastmail ! com
[Download RAW message or body]

I'm struggling to figure out how much varlink is actually used in the wild. Red Hat \
seem to be involved in it, and things they work on usually show up in Fedora pretty \
quickly, but there are no varlink libraries or tools installed by default, and the \
varlink resolver doesn't seem to be running. Podman (another project with RH \
involved) seems to have thought in 2020 [1] that varlink is more or less deprecated \
and ripped it out.

On the other hand, systemd seems to be adopting varlink more in the last few months - \
including creating its own 'varlinkctl' CLI [2] - but I haven't found any overall \
explanation of why, or what the long-term plan is, just PRs working on varlink \
support.

It looks like various design choices allow for a convenient CLI, which is something \
I've always found a bit awkward with D-Bus. Compare these two calls querying the \
default resolver/bus:

varlink call org.varlink.resolver.GetInfo
dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus \
org.freedesktop.DBus.ListNames

Basing the protocol on JSON makes it very approachable, especially for all of us who \
are most used to languages like Python, Ruby or JS.

[1] https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice.html
[2] https://github.com/systemd/systemd/pull/29325

Thomas

On Thu, 21 Mar 2024, at 03:23, Lawrence D'Oliveiro wrote:
> 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 »".


[prev in list] [next in list] [prev in thread] [next in thread]