[patch] initial conversion of glib bindings to use signatures

[Havoc Pennington]

On Fri, 2005-02-25 at 15:49 -0500, Colin Walters wrote:
> 
> Yeah, although GLib programmers are used to the type-unsafety of
> GHashTable anyways.
> 

The suckage here is that they are used to creating the type unsafety
themselves... there aren't APIs that return hash tables really.

> >> 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
> 
> Hmmm.  Yeah, I can see the value in #2.  

Had a long discussion with Owen where he made some convincing arguments
for the last one (convert to C struct).

Some ideas in this area:

 - we don't necessarily have to generate a struct at all, though we can.
We can just 
   declare that "(ii)" can be stored in anything that is:
   struct { dbus_int32_t field1; dbus_int32_t field2; }
   so while dbus-binding-tool will probably know how to generate such a
struct 
   decl, you can also just declare your own struct if not using dbus-
binding-tool.

 - an arbitrarily complex recursive type can be stored in a single
malloc 
   block, so we can ignore the "destructor" problem. Arrays and strings
   just follow the struct that points to them in the block.
  
   Exception: if dicts are GHashTable this breaks, I guess.

 - all interesting architectures use the same alignment for struct
fields, 
   but may not use the same alignment for structs (dbus aligns all
structs
   on 8-boundary regardless of field types)

 - I wonder if the convert-to-struct code should be in dbus-message.h 
   rather than in the glib bindings. Basically just add a 
   dbus_message_iter_get_as_c_struct () which could be called for any
iterator
   and would return the entire complex type starting at the current 
   iter position. We could even allow using it for the entire 
   message. So a message with "int, string, int" could be converted
   to struct { dbus_int32_t; char*; dbus_int32_t; }
   
   If this is in libdbus a minor hack is needed to allow passing
   in an alternate malloc function (such as g_malloc) probably.

> >One suckage here is the need to wrap all the message iter stuff.
> 
> So on the client end, if the frobnicate method's input signature was
> "s(ii)" and output signature was "(ii)", the code might look like this:
> 
> DBusGStructureIter iter;
> DBusGStructureIter ret_iter;
> GError *error = NULL;
> 
> dbus_g_structure_init_append (&iter);
> dbus_g_structure_append_values (&iter, G_TYPE_INT32, 10, G_TYPE_INT32, 42, G_TYPE_INVALID);
> if (!org_freedesktop_NetworkManager_frobnicate (proxy, "Blah", &iter, &ret_iter, &error))
>   ...
> 
> printf ("returned %d", dbus_g_structure_iter_get_int32 (&ret_iter));
> dbus_g_structure_iter_next (&ret_iter);
> printf (":%d\n", dbus_g_structure_iter_get_int32 (&ret_iter));
> 
> 
> Or something like that?

Yeah, basically. 

> Have you had a chance to look at the patch, by the way?

Ah, I guess I didn't notice there was a patch. Your mail is confusing in
evo because the attachment icon always appears for the gpg key...

Havoc