Re: GVariant for prez!

[Simon McVittie <simon mcvittie collabora co uk>]

On Mon, 04 May 2009 at 20:30:13 +0200, Mikkel Kamstrup Erlandsen wrote:
> 2009/5/4 Simon McVittie <simon mcvittie collabora co uk>:
> > On Sat, 02 May 2009 at 13:02:39 -0400, David Zeuthen wrote:
> >>  o I'm worried that GVariant supports a superset of the D-Bus
> >>    protocol.
> >
> > Right, ideally GVariant as merged in GLib should support exactly the D-Bus
> > protocol (either by code deletion, #if 0, or getting more things into the D-Bus
> > protocol).
> 
> This argument has been repeated a few times by a few different people
> so I feel the need to oppose it. It has primarily been brought up by
> those with heavy roots in DBus-land and with my
> "get-dbus-in-glib"-goggles on I can understand this argument. Taking
> those goggle off a bit I think that supporting just the DBus protocol
> would be a mistake.

I'm not at all opposed to getting more things into the D-Bus protocol (and
with Lennart's fd-passing-over-D-Bus code, it seems we can no longer avoid
feature negotiation, so we might as well get some use out of it :-)

> Another thing is the ever-growing usage og SQLite for even trivial
> tasks. The common chant that SQL-schemas aren't part of the public API
> makes this even more problematic for deep integration on the desktop.

Of course, D-Bus being a freedesktop technology and all, we could ideally
get an equivalent of GVariant into Qt (and any other similar library)
and integrate deeply into *all* the desktops :-)

This relies on having a central specification for the type system, though,
and the D-Bus Specification seems as good a place as any for that. I've thought
for a while that the D-Bus spec should be split into "message passing" and
"object model" layers, and thinking about it, "data model" (which underlies
the message passing layer) needs to come before both of those.

> > GStored? GStorage? GRepresentation? (OK, that one's too long.) GBlob?
> 
> I agree that the GVariant name might not be the clearest from an
> API-design pow. GStructure, GStruct, GConstruct, GForm, GCell? The
> mathematician in me really likes GForm, but that is probably because
> mathematicians always call stuff they can't name properly "forms" :-)

I'd like to veto GStructure/GStruct because there is already a 'struct' concept
in D-Bus, and not all GVariants are structs. GConstruct sounds too confusing
given GObject's constructor(), constructed(), and construct-time properties.

I quite like GCell as a name. It's small, it can be part of a larger organism
or stand alone, it can be replicated, a signature describes it... biologists
might approve :-)

> Naming aside, my main point is that I've missed a good serialization
> framework in GLib on several occasions - ending up abusing GKeyFiles
> or GConf (there I said it, kill me now). If I had an on-disk
> serialization format that I could make part of my public API that
> would just be wicked! DBus is almost just a collateral bonus to me
> here.

Right, telepathy-mission-control 4 serializes to GConf (known bug) and MC 5
serializes to a GKeyFile, which is lossy.

    Simon