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
internally.)
> - 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_ARRAY DBUS_TYPE_STRUCT_ENTRY_BEGIN DBUS_TYPE_STRING DBUS_TYPE_VARIANT
DBUS_TYPE_STRUCT_ENTRY_END (or whatever the libdbus constants are really
called).
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 /
PyArgs_ParseTuple.
Regards,
Simon
Attachment:
signature.asc
Description: Digital signature