<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-forward-container"> <br>
-------- Original Message --------
<table class="moz-email-headers-table" cellpadding="0"
cellspacing="0" border="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: Why GVariant? (Re: Starting the kdbus discussions</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Thu, 02 Jan 2014 16:08:00 +0100</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>rony <a class="moz-txt-link-rfc2396E" href="mailto:rony@wu.ac.at"><rony@wu.ac.at></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organization:
</th>
<td>WU Wien</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td>Kay Sievers <a class="moz-txt-link-rfc2396E" href="mailto:kay@vrfy.org"><kay@vrfy.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>On 02.01.2014 15:02, Kay Sievers wrote:
> On Thu, Jan 2, 2014 at 2:20 PM, rony <a class="moz-txt-link-rfc2396E" href="mailto:rony@wu.ac.at"><rony@wu.ac.at></a> 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
</pre>
</div>
<br>
</body>
</html>