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

List:       freedesktop-dbus
Subject:    Re: D-Bus Versus Varlink
From:       Lennart Poettering <mzqohf () 0pointer ! de>
Date:       2024-04-03 8:27:46
Message-ID: Zg0TAlieyOseeIWb () gardel-login
[Download RAW message or body]

On Mi, 03.04.24 11:06, Lawrence D'Oliveiro (ldo@geek-central.gen.nz) wrote:

> Lennart Poettering wrote:
>
> > Suitable to streaming large amount of data (i.e. useful for listing
> > larger directories of things, where the dbus broker would normally
> > kick you off the bus)
>
> There is a solution to this, which takes slightly more work: open a
> pipe or socketpair, and exchange one end with the peer by passing a
> value of the Unix file descriptor type. Then you can do the bulk
> transfer without going through the D-Bus daemon.

Sure, of course. But what you are describing here is basically
foregoing D-Bus and using the side-channel. Varlink doesn't need that,
you can switch the connection to something else when you want, no need
to add any additional channel.

> > * JSON sucks for large integers.
>
> Surely this is a limitation of the existing libraries, not that of the
> JSON protocol itself. E.g. this works in Python:
>
>     import json
>
>     d = json.loads("{\"key\" : 18446744073709551616}")
>     print(d, d["key"] + 1)
>
> Output:
>
>     {'key': 18446744073709551616} 18446744073709551617
>
> If you don't want your JSON library to require support for
> multiprecision integers, then at least it needs to provide an
> intermediate representation as a simple array of decimal digits (plus
> sign, if present), with conversions available to/from standard C
> types--signed/unsigned int/long, with errors returned if the
> representation won't fit. If the application needs more than that, then
> it can explicitly link against a multiprecision integer library.
>
> Looking at how JavaScript itself deals with this
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON>,
> receiving high-precision integers is a little fiddly, but doable.

Sure. I am a Varlink proponent, I don't think the large integer thing
is a big problem (my suspicion is that the primary reason to ever use
integers with more than 53 bits is that you want to encode some
special nullification case in an UINT64_MAX or so, but given that JSON
has an explicit "null" type you don#t really need that anyway).

The varlink implementation we use in systemd can properly handle
integers in the range of INT64_MIN…UINT64_MAX anyway. And is written
defensively so that we can also parse integers formatted as strings
for compat with JSON-I recommendations.

Lennart

--
Lennart Poettering, Berlin
[prev in list] [next in list] [prev in thread] [next in thread]