Re: GVariant for prez!

[David Zeuthen <david fubar dk>]

On Mon, 2009-05-04 at 13:26 +0100, Simon McVittie wrote:
> On Sat, 02 May 2009 at 13:02:39 -0400, David Zeuthen wrote:
> >    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.
> 
> I don't think producing a high-quality D-Bus API from an existing C API is
> as realistic or useful as you think. A D-Bus API is an external interface,
> just like a C API, a file format or a network protocol, and as such it needs
> to be designed (and as in file formats and network protocols, there are
> conventions you can use, like DBus.Properties, but you still have to know how
> those conventions are applied to this particular use).

Just for the record, my opinion on what kind of API is not based on
"what I think" or something - it's based on years and years of
experience working with complex D-Bus APIs.

> Most of the Telepathy stack consists of code that was explicitly written for
> dbus-glib use, and even there, there are fewer situations than you might think
> where we can push an internal data structure straight into dbus-glib. In
> practice there's a lot of "take this list of GObjects, call this method on
> each of them, put the results in a GPtrArray and hand it to dbus-glib". It'd
> be no harder for us to put the results in a GVariant and hand *that* to a
> D-Bus binding.

In contrast, most D-Bus clients that I write these days are not based on
the "stick GValue in GHashTable, use GValueArray as a struct" design
because it's just incredibly awkward to work with. Instead, I marshal
these things into native concepts that every C programmer using GLib and
GObject is intimately familiar with.

For example, see gnome-disk-utility which is a client of DeviceKit-disks
(fairly complex D-Bus types being passed around) - e.g. when retriving
historical data on a disk, a(tdtsba(isiiiis)) gets returned as a
GPtrArray of GduAtaSmartAttribute objects. This makes it a ton easier to
actually use this data (drawing ATA SMART graphs, sticking it in a tree
view, whatever). Heck, anyone slightly familiar with GLib and object
oriented programming can use this. They *don't* have to sit down and
learn about other things like D-Bus signatures. Sticking to familiar
concepts allows your development team to scale, all that good stuff.
And, heck, should I want to add a field to that struct, I get compile
time errors so I know what needs to be fixed up.

(Of course all this marshalling code is currently hand-written, that's
the bug I'm trying to fix with GDBus.)

Anyway, I'm not really sure we're getting anywhere with this discussion.

You are arguing that everyone is forced to use a varargs API like
GVariant (and in the process learn that API and abandon exisiting GLib
datatypes and patterns - and also rewire the data model of their apps).

I'm arguing that the default should be to map to native GLib types - and
still leave the option for marshalling native D-Bus data structures,
such as GVariant, should they desire to do so. 

There is a lot of precedence for mapping IPC to native data types if you
examine prior art. It doesn't _necessarily_ make IPC any easier (it's
still IPC, cf. all the papers written about pitfalls about IPC that
we've all read many times), but at least it cuts down the learning curve
insofar that you can use existing data types and integrate with existing
code without you having to rewire the data model of your application or
write custom code to marshal things (which is the whole point of a type
mapping).

And, hey, as I said already, I think GVariant, with some suitable
changes and a rename, could be a *great* basis for this work. I just
don't think it's suitable API for application development.

     David