Re: GVariant for prez!

[Ryan Lortie <desrt desrt ca>]

Hi David

Thanks for your reply.

David Zeuthen wrote:
>  - GVariant brings in a completely new type system

That's not entirely true.  The DBus type system is being used and loved 
by many people already and GVariant is using that type system.  GVariant 
merely brings this type system into glib.

>  - The API looks very similar to DBusMessage and DBusMessageIter

I'd disagree here for two main reasons:

1) It's possible to remove GVariants from their parents.  ie: you can 
take one argument of a DBus method call (or one item of an array) and 
pass it around as a separate value.  This is not possible with DBusMessage.

For applications like dconf, this is critically important.  It allows 
using the same type system that is used to implement the message bus to 
pass data on your API without unpacking/repacking between two separate 
value container formats (say: deserialising from a DBusMessage to 
GConfValue type of thing).

On the flip side of this, it is also possible to construct more complex 
GVariants out of GVariants that are given to you by someone else (ie: no 
code for serialising a GConfValue into a DBusMessage along with other 
stuff).


2) The varargs construction/deconstruction vastly simplifies 
construction of complex value types when using C.  Consider how much 
code you need in DBus to create a structure containing a string and a 
varaint (say, containing an integer).

dbus:

open struct subiter
  add string
  open variant subiter
    add integer
  close variant subiter
close struct subiter

gvariant:

g_variant_new ("(sv)", "foo", g_variant_new_int (123));


> While I can see the general usefulness of having a DBusMessage-ish API
> being used outside libdbus let us focus on what it is we need (or a
> least what I think we need)

[I don't address most of these because they are not directly related to 
GVariant, although they could easily be potential users of it].

>  - Some kind of replacement for GConf. I understand your proposal is
>    not dconf per se, it's GSettings, right? Do you expect people to
>    use the GVariant API in GSettings?

It's possible, but it would be unusual.  One of the nice features of 
GVariant varargs support is that you can use it in your library to build 
APIs that are similar to g_object_get/set().  In the usual case, you 
would make a call that looks something like:

  // assuming "key" is boolean
  g_settings_set (settings, "key", TRUE);

which would use GVariant internally to collect the varargs list of 
arguments before calling a lowel level function like 
g_settings_set_value() which actually takes a GVariant *.

This is vaguely similar to how gobject can collect into a GValue before 
passing that to a call like g_object_set_property ().

> Basically my impression is that GVariant is a lot like DBusMessage and
> frankly, for application writers, I'm not sure that is good API (while
> for bindings / low-level stuff it is fine). Then again, I'm known to
> favor type-safety / generated code which some people regard as an
> extremist view. And I haven't tried GVariant so in some way I'm just
> speaking out of my ass.

Your key contention that GVariant is just like DBusMessage is something 
that I very strongly disagree with.  I created it mostly because I was 
unable to deal with DBusMessage and still do the things that I wanted to do.

Please try using it. :)


btw: after a lot of talk with some people who really know about DBus 
(like Telepathy developers) there is some consensus that demarshaling 
DBus messages into the "equivalent" glib types is extreme pain and tends 
not to work well.  Even in a code-generating approach, the real obvious 
cases can easily be dealt with: strings, ints, even arrays but it the 
sanity ends there.

When you get complicated types like arrays of structures, or really 
anything that contains a variant (array of pairs of strings and variant 
are common on a lot of APIs) then you're really in a bad place.  We 
don't currently have anything in glib to turn these things into without 
it getting messy.  I believe GVariant is an ideal candidate for the 
"closest convenient glib type" for a lot of types of data that you could 
get from the bus, and it's not that difficult or weird to use it either.

> Btw, the copyright headers in your glib branch still says GPLv3. You
> should probably change that...

Yes.  Thanks for noticing.  There are also some style issues with 
respect to things like placements of '*'s, etc.  These issues will 
obviously be fixed up.

Thanks again for the discussion.

Cheers