Why GVariant? (Re: Starting the kdbus discussions

[Lennart Poettering]

On Thu, 02.01.14 16:24, rony (rony at wu.ac.at) wrote:

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

You can stop asking this question: there are no such "real world"
comparisons. I mean, how would we make them? There currently is no such
thing as a fully converted kdbus system, simply because neither gdbus
nor libdbus1 have a native kdbus backend hence most traffic is routed
through the compat proxy. (And what is "real world" supposed to mean
anyway?)

However, you can draw quite a number of conclusions from the overall
designs already. For a full method call transaction (i.e. one method
call transferred over the bus plus one response back) you need 10 (!)
message copies, 4 complete validations and 4 context switches on
dbus-daemon+dbus1. On kdbus+gvariant you need 2 message copies (or less
when large messages are used), 2 validations and 2 context switches.

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

My userspace is still written in > 95% C code.

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

Well, but these programming languages certainly are not as ubiquitious
on Linux as C and its descendents is...

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

I think we have to agree to disagree here. 

Also, this string discussion has nothing to do with Gvariant/kdbus vs
dbus-daemon/dbus1 marshalling, as both schemes make the exact same
restrictions here...

Lennart

-- 
Lennart Poettering, Red Hat