Re: GVariant for prez!

[David Zeuthen <david fubar dk>]

Hey Ryan,

I took a closer look at GVariant today so here are some more comments,
take them, leave them or do whatever you want with them ;-)

Most of these comments are general but, for other readers, it might help
to also read the conversations in

 http://bugzilla.gnome.org/show_bug.cgi?id=579571
 (GVariant discussion starts around comment 70)

to see where I'm coming from.

 o In general, I think GVariant is a very useful data type since
   you can serialize instances to disk and send them over the
   network or to different processes or whatever.

   Especially for something like replacing GConf, this is extremely
   useful - no doubt we want to avoid IPC overhead where possible (e.g.
   read from shared memory or files or whatever) and use IPC where it
   makes sense (for transactions involving writes). It's nice here to be
   able to use the same data type, no doubt about it.

 o Any particular reason this is not based on the base object class?
   There's a bunch of useful things in GObject such as

   - Subclassing
   - Data associations (e.g. g_object_set|get_data())
   - GInterface support
   - Weak references

   and when bug 557100 is resolved it seems the cost of basing GVariant
   on the base object class shouldn't matter.

 o It seems like you (or Simon or both) expect GVariant to be the only
   container type in town for C bindings for D-Bus (as per the D-Bus
   library bug report). E.g. you expect the C programmers to deal with
   a{ss} as a GVariant instead of the more natural type GHashTable.

   My view is that it's not really realistic to do this, I think it's
   a convenient thing that I can get/pass well-known data-types like
   GHashTable or GPtrArray from/to remote objects. This allows adding
   D-Bus support to existing programs without fundamentally changing
   how their data is represented and not having to deal with a vararg
   based API should you choose to generate code.

   It also seems particularly awkward to not map D-Bus APIs to native
   APIs (in GLib, GptrArray, GArray and GHashTable are considered native
   APIs for collections) - by the same token, would you expect Python
   users to use GVariant? No, they'd want to use the native types so
   they have things like hash table literals etc.

   Specifically, there is no equivalent of g_hash_table_lookup() etc.
   right now on GVariant but I suppose you can add that.

   (Btw, if GVariant was based on GObject and we added collection
    interfaces to the GLib stack (like some people want, cf. bug
    560061), then you'd just make GVariant implement the these
    interfaces and that would solve the "there is no
    g_hash_table_lookup() equivalent" complaint.)

   I realize that some people are not opposed to the GVariant type
   of programming. E.g. build your data up basically using an iterator,
   much like the way you build a DBusMessage. Obviously, I can't speak
   for others, but I personally don't like that kind of API unless I'm
   tooling around with simple D-Bus services. YMMV.

   That said, if we were to add the GDBus stuff I'm working on, I don't
   think we should antagonize users that want this. Not so much because
   choice of what collection API to use is great (as a general
   sentiment), more because there are legitimate reasons for why you
   want this cf. the GSettings example.

   (There's also the concern that GLib is so low in the stack and it's
    generally not wise to force too many dogmas on people - e.g. for
    D-Bus support, force people into using GPtrArray, GArray, GHashtable
    _or_ force people into using GVariant. We also want to be careful
    not to paint ourselves into any corners from which we can't escape.)

 o I'm worried that GVariant supports a superset of the D-Bus
   protocol.

 o I don't see any tests cases at all (or am I looking in the wrong
   place) - this worries me.

 o I don't really like the name, I don't think it adequately
   describes what GVariant is: a serialization format with an API
   to access and build the value. So, I'd call it GDBusValue instead
   since that really is what it is.

A concrete plan for landing the GVariant (which, as the douche I am, is
referring to as GDBusValue in the following) could be to make it part of
the GDBus work I'm doing

 o Probably we'd switch GDBus from using DBusMessage to GDBusValue for
   building messages.
   - maybe we'd want a dbus_message_demarshal() that didn't validate
     the data (since we'd trust GDBusValue for this) or maybe it's not
     worth it (most probably is, but profiling would be good here).

 o The C API for invoking methods / emitting signals would also accept
   G_TYPE_DBUS_VALUE. This, basically, allows you to feed raw D-Bus
   messages.

 o We'd have a way for the code generator to read an annotation on
   whether you'd want e.g. a GHashTable or a GDBusValue for a type
   signature a{ss}. Also a command-line switch.

In fact, I was already considering having a boxed type for DBusMessage
so people can do this. But it seems wiser, as you have demonstrated, to
encapsulate DBusMessage in a native GLib type since it is useful outside
the world of IPC (where libdbus-1 is not available).

Of course all this is up to the GLib maintainers (maybe they'll merge
GVariant, maybe they'll merge GDBus, maybe they'll merge nothing!) but I
don't think landing both GDBus and GVariant without some kind of
integration work (perhaps like what I proposed) is ever going to work.
It would be truly bizarre.

     David