Why GVariant? (Re: Starting the kdbus discussions

[rony]

-------- Original Message --------
Subject: 	Re: Why GVariant? (Re: Starting the kdbus discussions
Date: 	Thu, 02 Jan 2014 16:08:00 +0100
From: 	rony <rony at wu.ac.at>
Organization: 	WU Wien
To: 	Kay Sievers <kay at vrfy.org>



On 02.01.2014 15:02, Kay Sievers wrote:
> On Thu, Jan 2, 2014 at 2:20 PM, rony <rony at wu.ac.at> wrote:
>
>> 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?
> Because it is similar enough to be not surprising and it solves quite
> a lot of problems which the old D-Bus format has. It has sane
> alignment rules, and it provides "seekable" data describing the
> containers, and it not just a stream of bytes, and so on.
>
> Read 2.1, 2.3.3, 2.3.4 in the document. It's by far the better choice
> today. The Glib D-Bus code (which does not use libdbus) uses it
> internally already, so there was already a major user today.

Yes, I have read the entire specification, before placing my questions.

2.1 Why not DBus: these are GVariant-only related reasons it seems, *after* having decided to use
GVariant instead of dbus. E.g.: "To do so, however, would conflict with a number of requirements
that were established for GVariant."

2.3.3 Simple Containment: not clear what benefits this allows for in real life, if any at all (given
the added complexity of de/serializing), hence asking for timing comparisons (for real world
deployments).

2.3.4 Alignment: in what way is this a problem in dbus serialization? Are there any timing
comparisons between dbus and your GVariant implementation (for real world deployments for
serializing, transporting, deserializing)?

> If we change the entire transport anyway with kdbus, we can switch to
> the more efficient GVariant at the same time. The compat proxy will
> provide the old marshalling for the old transport and re-marshal as
> needed, so all should continue to work as it works today.

Are there any comparison timings available for your statement/expectation: "the more efficient
Gvariant" (using real world deployments and not edge cases)?

>
>> 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?
> Strings cannot *contain* \0., they are still \0 terminated.

Why not? This is a time where the old C-style "string"-convention has been long forgone.

There are plenty of programming languages that allow strings to contain \0. Their implementations do
not require to have strings terminated by \0.

A library/transport should be language-agnostic w.r.t. strings. An implementation that forces the
old C-style convention for "strings" to be terminated with a nul byte \0 does not appear to be very
"up-to-date". Also, not defining an explicit string encoding in a world that uses all kinds of
different string encodings appears to be quite error-prone. 

---rony


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140102/98deda9b/attachment.html>