Service-Side GLib Bindings

[Havoc Pennington]

On Mon, 2004-08-16 at 18:25, Paul Kuliniewicz wrote:
> > 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?

Some old mails, which may not be 100% right anymore, but maybe give some
history:
http://freedesktop.org/pipermail/dbus/2004-March/000817.html
http://freedesktop.org/pipermail/dbus/2004-May/001162.html

> > 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()?

The node names would only be used for introspection, not for generating
the GObject type libs. Just as the C method name attribute would only be
used for generating type libs, and not in introspection. It isn't a
fully elegant system. ;-)

> 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.

Marshaller should always call the function in the GMethodInfo.

> 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

We just have to define the rules, and require them to be followed. It
should be d_bus_message_foo probably according to the rule. Remember we
aren't trying to export arbitrary objects, but rather objects that are
being implemented specifically as D-BUS object implementations.

Havoc