Re: GVariant for prez!

[Christian Dywan <christian imendio com>]

Am Sat, 11 Apr 2009 13:55:36 -0400
schrieb 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.
> 
> [...]
> 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.

Using G_TYPE_FOO in the API is imho a lot more agreeable than any new
string signature. Sure it's more to type, but at the same time it's
more comprehensible. :)

> 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 think this goes in the general direction of whether a particular
GType can be serialzed and deserialized at all. For what I want, an
object that for example represents an XML document, can very well be
serialized. Of course that is entirely specific to the object type.
Attempting to bring an object into a storable format is otherwise not a
stupid idea imho.

Maybe GType needs an interface so any type can implement what boils
down to g_type_serialize, g_type_deserialize and g_type_can_serialize.


If you think passing types to DBus that are not part of DBus will lead
to problems, it might just be a matter of documenting that in Glib.

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

You are asserting that something like a "gint" or "guint" is not
something that can be saved to disk. Please take another look at the
signature of g_key_file_get_integer. At the very least, you shouldn't
compare GKeyFile with GVariant if you think one of them is broken by
design, otherwise you are contradicting yourself :)

That said, it is all too common, for better or worse, to work with
numbers of unknown physical size, including storage to disk. It's fine
with me to say it may not be a good idea, but I don't believe this is a
DBus related problem at all. Granted, making it look like a GVariant
specific issue is easier than trying to deprecate "gint" and "guint".

Just my 2 pfennig,
    Christian