Re: GLib plans for the next cycle

[Havoc Pennington <havoc pennington gmail com>]

Hi,

On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson
<will thompson collabora co uk> wrote:
> I don't think that relying on having correct introspection data to
> marshall messages is a sound idea for a DBus binding.

There's no way you can marshal a message without the introspection data.

It can be implicit (i.e. you happen to pass an int, or an array of
foo, so the marshaler marshals an int or an array of foo); or it can
be explicit (someone specifies the signature somewhere); but either
way, the two sides of an IPC connection have to agree in advance at
code-writing time what the signature of something is.
(Modulo overloading/variants, i.e. an agreement to do switching on
type at runtime, of course.)

The JavaScript/gjs dbus bindings work very well, and there's no dbus
signature stuck to a JS integer type to say what kind of integer it
is. The way it works is that you provide the interface and the types
get coerced. So if an interface takes an int8, you can pass in an
integer or a double or a bool or anything that can convert to int8,
and it gets converted.

The need for sticking all this extra goo in GType for dbus-glib's
benefit is arising because dbus-glib is broken. If all the design
decisions are correct, said goo should not be needed.

Which is good, because the goo is completely unnatural in C, not to
mention bloated. When was the last time you made a GHashTable full of
GValue and you were *not* using dbus-glib? The answer for me is I've
been writing "G" C for a decade and have never done this. A decent C
binding isn't going to "leak" freaky data types and data structures
into the rest of your program.

The only place this type info should need to be in a *value* (rather
than an interface description) is for variants. That's where GVariant
comes in.

> But for this to be useful, the binding has to support
> complex types just as much, if not more, than simple ones, particularly
> in a language like C.

The *binding* needs to support complex types, but the *language*
doesn't. In effect, libgobject defines a dialect or superset-language
of C. If it were true that GType and libgobject had to exactly support
all the types dbus does, it would also be true that to map dbus to
python or JavaScript, those languages would have to support exactly
all the types dbus does. But that isn't true.

The problem arises when you try to specify dbus signatures using the
type system of the *language* instead of the type system of *dbus*.
This is simply a bad idea. The introspection data - wherever it lives,
implicit or explicit - should be in dbus's signature format, or
something semantically equivalent. It doesn't make sense to express a
dbus signature (or more generally, the signature of a serialized data
blob) in GTypes, imo. Just makes a mess.

Havoc