Re: GDBus API Questions; was: GDBus/GVariant plans for next GLib release

[David Zeuthen <david fubar dk>]

Hey Mikkel,

On Thu, 2009-10-15 at 08:24 +0200, Mikkel Kamstrup Erlandsen wrote:
>  * Can I register a GDBusInterfaceVTable without registering an
> object? The use case I have in mind is something akin to dynamically
> spawning objects on the server side when messages are send to objects
> under a given path[1]. Fx. when messages are send to
> /org/example/item/* I create the item matching * dynamically. Ideally
> one would register the vtable for objects matching a regexp. This
> would facilitate RESTful message passing on the bus.

Yeah, there's a TODO in gdbusconnection.h to say we need something like
that - it would be similar dbus_connection_register_fallback() [1]. We
probably want a separate GDBusHierarchyVTable with functions to a) list
objects in the "directory"; and b) get introspection data for objects in
the "directory". 

I haven't given this much thought yet - I guess playing around with it
helps - we also need to ensure that object mappings (e.g. generated
GDBusProxy subclasses - see below) plays nicely with it.

[1] : http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#g1aa656b16bda11e8042e5eb4dc8f69a8

> * Properties and signals in GDBusProxy are namespaced?

Yeah, this is because I envision that we're going to have code
generators (for those of us wanting that), like eggdbus-binding-tool,
spit out the follow things for every D-Bus interface

 - A GInterface FooBar with a VTable for methods and GObject
   properties and GObject signals.

 - A subclass of GDBusProxy, FooBarProxy, implementing FooBar. You'd
   use this subclass in g_bus_watch_proxy() by passing
   FOO_TYPE_BAR_PROXY for the @interface_type parameter.

   Now, if the properties/signals in GDBusProxy wasn't prefixed
   with g-dbus-proxy things wouldn't work if you had a property
   called e.g. 'flags' (or rather, a property for which the
   g-name would map to 'flags').

 - A static function to export a GObject implementing the
   FooBar GInterface

    gboolean
    foo_bar_register_object (GDBusConnection  *connection,
                             FooBar           *foo_bar,
                             const gchar      *object_path,
                             GError          **error);

   that just calls g_dbus_connection_register_object() under the
   hood (taking care of the other parameters). For hierarchies, I
   envision a similar function

    gboolean
    foo_bar_register_hierarchy (GDBusConnection  *connection,
                                FooBar           *foo_bar,
                                const gchar      *object_path,
                                GError          **error);

> * g_bus_unown_name() only takes the owner_id and not the connection to
> unregister on? I see how this can be made to work, but there's
> something about it that makes me a bit worried if I own the same bus
> name on connections to different buses (this is a theoretical
> possibility right?). Probably only an extremely little problem in
> practice, but here goes the nitpicker bringing it up anyway ;-)

All ids returned by GDBus are supposed to be unique so this shouldn't be
a problem.

Thanks,
David