Hi, On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson <will.thomp...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list