Hi, On Sat, Apr 11, 2009 at 11:06 AM, Matthias Clasen <matthias.cla...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list