Why GVariant? (Re: Starting the kdbus discussions

[Kay Sievers]

On Thu, Jan 2, 2014 at 4:24 PM, rony <rony at wu.ac.at> wrote:

> the added complexity of de/serializing), hence asking for timing comparisons (for real world
> deployments).

This is not about micro-optimizations, it's about using an advanced
and better concept here, hence there are no direct comparisons. The
implementation changes, the transport changes, Gvariant is widely used
already; it's just that it's the right time to do the marshalling
switch too for kdbus use cases. Compat is provided, the old D-Bus
implementation can catch up if it wants, so there should be no
problem.

Nothing should hold us back from switching now, especially not for
arguments like "complexity", it is sane and straight-forward stuff, it
does not matter at all here, looking at the big picture.

> >> 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.

A D-Bus string is a well-defined basic type, just use a byte-array and
not a string if you want to encode magic sequences in it.

Kay