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 > > http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo > > 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 problems. > 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. Regards, -- Will
Attachment:
signature.asc
Description: OpenPGP digital signature