[patch] initial conversion of glib bindings to use signatures

[Havoc Pennington]

On Thu, 2005-02-24 at 15:09 -0500, Colin Walters wrote:
> One thing I'd like to discuss is what exactly various container types
> should map to in GLib.  I would think that:
> 
> a{..} -> GHashTable

Yes, dict to hash table seems right. Though it's completely untypesafe
and awful on some level.

> A bit tricky in the general case like a{ia{sv}}, but shouldn't require
> copying the actual data.  Seems like there's a sensible mapping from the
> various types to hash functions and equality tests.
> 
> a -> GArray
> 
> Unfortunately it doesn't look possible to create a GArray which just
> points to extant data.

The glib bindings have to copy the data because the DBusMessage is never
passed out, so nobody is holding a reference to it.

> The thing I'm most unsure about is how structures will work, both on the
> client wrapper end and the server side.

The options I know of are:
 - they are hashes from string to GValue
 - they are a special object with iterator, like DBusMessage
   (in fact it could just be DBusGMessage with the iter stuff also
wrapped)
 - the CORBA thing (convert to a C struct)

My suggestion is #2, on the theory that usually a struct will really be
some special type like a pixbuf or point or rectangle, and people will
want to add awareness of that specific special type. i.e. I imagine
things like gdk_rectangle_from_dbus/to_dbus

We could even support supplying a "struct marshaller" like that.

i.e. approach structs in basically the same way we're approaching
everything else: assume they have to be converted to some native
representation.

One suckage here is the need to wrap all the message iter stuff.

Havoc