Service-Side GLib Bindings

[Paul Kuliniewicz]

On Sun, Aug 15, 2004 at 01:00:52PM -0400, Havoc Pennington wrote:
> On Sat, 2004-08-14 at 17:31, Paul Kuliniewicz wrote:
> > I've been looking at what's left to implement to get the service-side
> > functionality of the GLib bindings operational,
> 
> Yay!
> 
> Scan through doc/TODO, though there's nothing earth-shattering in there.
> 
> I'm assuming you've seen mails on the general plan, which was to go:

I don't think I have.  Any particular messages I should look for?

> > What's the purpose of the <node> tags in the XML introspection data?
> > All of the other tags are pretty straightforward, but I'm not sure what
> > <node> represents.  An example of what this XML introspection data
> > should look like would be great.
> 
> The idea is that you can query a tree of objects in the object path
> tree, e.g. all children of /foo/bar in one go.

So the XML specifies both the objects' interfaces and where they go in
the path hierarchy?  Doesn't that conflict with saying where the object
goes in the call to dbus_g_connection_register_g_object()?

> > [How is all this supposed to work?]
> 
> You should assume that MethodInfo/ObjectInfo could be totally wrong -
> they were just some initial sketches at how it might work.
> The goal should be to have a minimum number of static variables
> representing the metainfo/type-library, and have each of those variables
> be read-only (const) data. This will make things much more efficient.
> Runtime speed is probably a secondary goal, within reason.
> 
> That said, I'll explain what the initial sketch was supposed to mean:
> 
>  - GObjectInfo::data is a huge const string with the method names and  
>    signatures. I don't know what format it's in, that's TBD.
>  - GMethodInfo has the function pointer, the marshaller, and an 
>    offset into the huge const string
>  - all the GMethodInfo are in a big const array, pointed to be 
>    GObjectInfo
> 
> So the generated data might look like:
> 
> static const char object_info_data[] =
> "some_method_name,whatever,whatever,another_method_name,whatever";
> 
> static const GMethodInfo object_method_infos[] = {
>   { c_function_name, marshaller_for_this_function, 0 },
>   { other_c_function_name, another_marshaller, 20 },
>   { NULL, NULL, 0 }
> };
> 
> static const GObjectInfo object_info = { 
>   0, /* version */
>   object_method_infos,
>   object_info_data
> };
> 
> Also generated would be any needed marshallers (the common marshallers
> might be included in libdbus-glib, and then uncommon ones have a
> separate copy in each generated file). 

OK, that makes a lot more sense now.  The structs will need some
adjusting (right now there doesn't seem to be a way to tell the
marhshaller which function to call), but the basic idea looks good.

> It's possible the object_info_data string only has method names I guess,
> since the method type signatures are known to the marshaller.

Right.

> The obvious approach would be to have GMethodInfo include the method
> name. However, this creates a bunch of extra symbols in the object file,
> and has a noticeable impact on app startup time. Qt 4 moves to the "one
> huge string" approach for that reason, we may as well copy the good
> idea.

Interesting.  I wouldn't have thought that could make a significant
difference.

> >   Will the
> > bindings need to add listeners for each exposed signal on the object?
> 
> Yep. I guess this might have to be part of the GObjectInfo, there's
> nothing in there yet about signals.

I'll hold off on handling signals until I get method invocation working.
It shouldn't be *too* much harder, though.

> > And, finally, a non-implementation question.  D-BUS methods usually have
> > names that LookLikeThis, but GLib methods have names that
> > look_like_this.  Which naming convention is the "right one" to use for
> > GLib methods exposed by D-BUS?
> 
> I was converting between them, see wincaps_to_uscore(). Which is kind of
> strange, but seems right to me. The general principle here is that you
> have to write the GObject following certain conventions to make it work
> as a D-BUS remote object, and so one of the conventions may as well be
> that it sensibly autoconverts to wincaps.

Will that work in practice?  There's the problem of what consecutive
capital letters mean and how they should be split.  For example:

GHashTable  -> g_hash_table_foo
DBusMessage -> dbus_message_foo

In any case, worrying about this can easily wait until the functionality
gets taken care of.

> A final note, I think you'll have to add some stuff to the XML format,
> namely for methods you'll need a c_method_name attribute I bet. This
> would be in the XML format used for this purpose but not returned from
> an Introspect() call.

That's pretty much a given, unless you're going to rely on naming
conventions being consistent and a bit of cleverness.

> Good luck, please ask questions, I'm happy to help get this done.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://freedesktop.org/pipermail/dbus/attachments/20040816/a79d4eed/attachment.pgp