Why GVariant? (Re: Starting the kdbus discussions

[rony]

On 02.01.2014 15:53, Lennart Poettering wrote:
> On Thu, 02.01.14 14:20, rony (rony at wu.ac.at) wrote:
>
>>> I am certainly not going to wdiff this against the bus spec for
>>> you... Note that in the dbus spec we should not document this anyway,
>>> but simply refer to glib's/ryan's spec for the marshalling.
>>>
>>>> If I can connect with AF_UNIX and communicate the same way on the
>>>> wire, then it's still D-Bus and I really don't see the problem here.
>>> Yes you can, it's compatbile with that.
>> Two questions:
>>
>>   * Why did you chose to use a GVariant encoding and not sticking to the standardized and
>>     established dbus encoding? What were the pro and what were the cons arguments for that
>>     (surprising) decision?
> This requirement has been adopted on request of Canonical's Ryan Lortie,
> who designed GVariant. In a way GVariant is just version 2.0 of the dbus
> marshalling. In the user interface it is mostly identical (i.e. all
> dbus1 signature strings are also gvariant signature strings, though the
> reverse is not true), however it is slightly more powerful (as it knows
> MAYBE types), 
That (maybe types) could be always added to dbus serialization. here have been discussions about the
maybe type in dbus for many years.

> a bit cleaner (since in gvariant the serialization of a
> specific data object is always the same regardless what comes before it,
> which is not the case for dbus1 marshalling), and more efficient (as you
> can seek to any element in an array or struct freely in O(1) time, even
> if the elements have a variable length, which was O(n) before with n
> being the number of elements).
Well that may be the case in theory, but how about real world programs? How about timing comparisons
for real-world use cases dbus vs. gvariant (real world usages, edge cases)?

> GVariant has been part of GLib since a long time, and is used as storage
> format of dconf among other things. Using GVariant as transport
> marshalling hence makes usecases like this (i.e. where you frequently
> use the same data on disk and on IPC) particularly efficient.
What about systems that do not have GLib?

Implementing GVariant is possible of course, but seems to be more complex (and hence more
error-prone) than dbus de/serialisation.

> Note that the format string extensions GVariant makes on top of dbus1
> are already listed in the dbus spec, and marked for future extension
> there, so the groundwork for actually making Gvariant work as dbus
> marshalling has alraedy been laid.
>
>>   * Also, I was surprised to learn that (among other things) using
>>     GVariant one must not transfer strings that contain nul bytes
>>     (0x00) byte (cf. section 2.4.5 Strings in the above mentioned
>>     pdf)?  Why is that?
> You cannot do that on dbus1 marshalling either. This is not a change.
>
> For security reasons it is always a good idea to enforce certain things
> on the data you transfer, like compatibility with C strings or UTF-8
> validity.
Are you sure? AFAIK dbus allows the transport of UTF-8 encoded strings, which AFAIK may contain nul
byte characters.

---rony