Re: GLib plans for the next cycle

David Zeuthen wrote:
> On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
>> Even if we have support for querying the element type of an array, for 
>> example, we can get into situations where we can still have type errors. 
>>   Consider the case of an array of arrays of strings (which is a fairly 
>> simple DBus type: "aas").
>> In this case, if you have a GArray, and query its type you will see the 
>> answer is "G_TYPE_ARRAY".  This doesn't help you very much.  You have to 
>> grab one of the inside arrays and query its type.  If the top array 
>> happens to be the empty array then you're really in trouble because now 
>> you have no way of determining the (complete) type of this empty array.
> If you are not using a D-Bus variant this information is explicitly
> available as part of the interface contract and it is also in the the
> introspection data
> as a D-Bus signature.

I don't think that relying on having correct introspection data to
marshall messages is a sound idea for a DBus binding. The C
representation of an 'a{uas}' where the values are all the empty list
should contain all the information you need to determine its D-Bus type.
It sounds like with EggDBus that's not possible without you discovering
the type by external means. If the C-side type system isn't powerful
enough to express the D-Bus-side types (which GType isn't), then the
C-side type system should be improved. Gluing the D-Bus type onto the
side doesn't sound like a clean way to do this to me.

Apparently, back when Telepathy was started, dbus-glib used to have a
similar problem with collections containing structs. It relied on
inspecting the contents of a GValueArray to determine the type of the
struct it represents, which obviously can't work for a(ss) since the
array might be empty. (Rob Taylor fixed this by adding a parameterized
struct type.) More recently, Rob McQueen had to fix dbus-glib to allow
complex types in maps. If the binding gets the type system right and
complete from the start, problems like this (and the current situation
where dbus-glib can't send 16-bit ints, causing interoperability
problems with bindings which expect them) won't arise later.

Talking about switching EggDBus to use GBus or GVariant in the future
seems like a non-starter; it would inevitably involve breaking the API.
So before putting a D-Bus binding into GLib, we should make sure it's
good enough to represent D-Bus cleanly, without needing the library user
to jump through hoops to make it work.

> The point is that you can always get to the D-Bus signature and from
> that you can infer the complete type.

dbus-python has shown that that's not true. When marshalling a dict (for
instance), it has to guess what the type is, and it sometimes guesses
wrongly, leading to hard-to-debug problems. It tries to quietly
introspect behind your back to work around this, and that too causes

> The set of distinct D-Bus signatures you encounter in a app where you
> would need to do this (e.g. no need to do this for primitive types) is
> most likely bounded to a couple of dozen types at the most (unless you
> are some odd-ball corner case like a D-Bus version of gconf-editor) so I
> don't think this is a big deal at all.

I think regarding types more complicated than 'as', 'b', 'i' etc. as
"odd-ball corner cases" is a mistake, particularly when talking about
one of the core components of the GNOME platform. The fact that D-Bus
has an expressive recursive type system is good, since it means you can
model interesting concepts without forcing them into an incorrect
representation. 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.

Telepathy uses some pretty complex D-Bus types; an example that comes to
mind is 'a{ua(a{sv}as)}'. If working with this type in the standard GLib
D-Bus binding is no less painful than it currently is with dbus-glib,
then using a component of the GNOME stack with a standard GNOME binding
will be unnecessarily difficult. I really don't want to end up in a
situation where I have to use an external library instead of the one
inside GLib to make working with Telepathy less painful.


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]