Re: A few comments on GVariant

On Mon, 30 Nov 2009 at 13:27:02 +0100, Christian Persch wrote:
> - space efficiency: I was trying to build a variant containing some
>   data, and multiple dicts to get at the data from various keys. i.e
>   "a{sv}a{sv}a{sv}". I though that if I constructed the data
>   GVariants first, and then added these to the dicts (i.e.
>   v=g_variant_new(), add (key1, v) to dict1, add (key2, v) to dict2
>   etc), the resulting blob (g_variant_flatten
>   + get the data out) would contain that data only once instead of once
>   for each dict it was in.

The D-Bus serialization format (which is also the GVariant serialization
format) doesn't have backreferences to previously-serialized data, so yes,
your data will get duplicated if you do this.

In practice, the big cost on D-Bus tends to be number of round trips /
wait-for-reply operations, rather than the number of bytes transferred, so
a bit of redundancy isn't a big deal.

I can see that the tradeoffs for storage on disk aren't the same as the
tradeoffs for D-Bus; but, gzip the blob? :-)

(Having backreferences would break compatibility between GVariant and D-Bus,
and would also break the desirable property that parts of a message are
entirely independent - as I understand it, GVariant takes advantage of that

> - there should be a convenience function that takes a dictionary
>   variant and turns it into a GHashTable (I was surprised that
>   g_variant_lookup[_value] just iterates over the whole thing until a
>   match is found)

As I mentioned on a related bug, I'd be inclined to say that the lookup
function should construct a cache the first time, and query it subsequently
(so it'd be O(n) the first time it was used, and O(1) thereafter).

> - the code uses literal 'X' / "X" in many places; IMHO using
>   G_VARIANT_TYPE_CLASS_X / G_VARIANT_TYPE_X would make the code more
>   readable / informative

Perhaps it's a sign that I do too much D-Bus, but I find code that uses the
plain signature strings ("a{sv}") to be much, much more readable than
DBUS_TYPE_STRUCT_ENTRY_END (or whatever the libdbus constants are really

The signature characters are all quite mnemonic, apart from the 16- and 64-bit
integers (I can never remember whether 't' or 'x' is the unsigned one).

There's lots of prior art, notably printf/scanf and Python's Py_BuildValue /


Attachment: signature.asc
Description: Digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]