Re: GVariant for prez!

[Havoc Pennington <havoc pennington gmail com>]

Hi,

On Sat, Apr 11, 2009 at 11:06 AM, Matthias Clasen
<matthias clasen gmail com> wrote:
>
> What David is saying (and I'm sure you understood) is that glib
> already comes with a type system, namely GType. Adding a completely
> separate one next to it in the same module is problematic, even if it
> is a well-loved one.

I'm trying to think about this myself.

Here are some thoughts.

* glib serialization has been discussed in the past, e.g.
http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00021.html

* GVariant is basically a particular serialization format. It happens
to use the same types as the dbus format.

* Using the same types as dbus is convenient in the sense that a
single API can support a dbus binding and say an mmap'd file format.
For something like an icon cache or typelib, this dbus-based
serialization format could be a good basis for a freedesktop.org spec
for the cache format.

* GType does not map 1-1 with a serializable type system.... there
will always be non-serializable GType, because GType supports opaque
objects and pointers. dbus and gvariant only support "plain old data"
and can only express differences that matter on the wire, for example,
there is no 'long' type with unspecified size since putting an
unspecified-size thing on the wire or on disk does not make sense.

* another complexity of GType with serialization is that it's
unbounded and extensible, while for interoperability you want a
serializable type system to be limited to some known set of types.
(perhaps with hints or tags in lookaside introspection data)

* a lesson of dbus bindings I think is that it doesn't work to
completely hide the dbus type system. You always end up needing the
ability to specify the dbus type that the language type (GType, Python
type, JS type) should be coerced to. This is because there's
ambiguity, e.g. the dynamic languages have one integer type not sized
integer types, or string vs. byte array, or whatever.


* I'd say the rationale for GVariant is to have a serialization API
that supports two cases: binary mmap files, intended for use in dconf
at least, and dbus. These are two commonly-desired features in the
desktop. It seems logical to support them in a similar way.

A question is whether these two cases can be nicely supported while
exposing only GType. Maybe there are two levels of this.

1. expose type signatures as a list of GType; probably a little less
convenient in that the API where you provide a signature string tends
to be shorter:
 foo("ii", 10, 42)
vs.
 foo(G_TYPE_INT32, 10, G_TYPE_INT32, 42, G_TYPE_INVALID)

The signature string thing does make you learn some custom syntax.
It's basically printf() vs. operator<< in a sense.

In the second case, where GType is specified, you have to know that
only a short whitelist of GType are allowed; only sized integers, no
objects, etc.

Some sort of G_TYPE_SERIALIZED_DICTIONARY, G_TYPE_SERIALIZED_STRUCT
types would need to be introduced I think to support the dbus format
or a format like it. Not clear how this works out. You could use
G_TYPE_HASH_TABLE, G_TYPE_LIST but in some real sense that's a hack;
much as allowing G_TYPE_INT (rather than sized int) would be a hack;
the underlying format is not "really" storing those GType, though it
can be converted to or from those GType. Another way to put it,
G_TYPE_ARRAY means "GArray", not "an array". Or another aspect of
this, do you allow LIST, SLIST, ARRAY to all be synonyms for the
on-disk array type? It's quite confusing to sort this out.

Hiding the signature string format and using GType for that seems like
it does not change anything semantically, it's just cosmetic in some
sense.

2. try to use GLib types instead of having a custom value type, i.e.
the dreaded GHashTable of GValue, or GArray that is a "struct". This
would seem to be both inconvenient, incomprehensible, and so bloated
it may destroy the purpose of using mmap'd files. So some sort of
"serialized data value" object like GVariant would appear to be
needed? In short, if you have a dbus struct or dictionary, or mmap
file struct or dictionary, what is the API to access that?

This doesn't seem cosmetic to me. It's a fundamental question whether
there's a "serialized data value" object and which types can go in it.


* I would think of the type system of GVariant more like
g_key_file_get_integer(), g_key_file_get_boolean(),
g_key_file_get_integer_list() than it is like GType. The GVariant
signature format is obviously far more complex than what GKeyFile
supports; but *conceptually* it's equivalent to GKeyFile, right? It's
pretty much an API for mmap'd files and for dbus IPC, just as keyfile
is an API for .ini text files.

* I almost want to call it GBinaryValue or GBinaryData or something
rather than GVariant, despite the extra typing

Havoc