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

[David Zeuthen <david fubar dk>]

Hey Mikkel,

On Mon, 2009-10-26 at 23:52 +0100, Mikkel Kamstrup Erlandsen wrote:
> > I just looked over the newly introduced
> > g_dbus_connection_register_subtree() and related data structures, and
> > I think it will fit very nicely with what I am going to need. All in
> > all it looks really sweet, good work.
> >
> > One thing though is that as I read it objects in a subtree must be
> > known before method calls are accepted to them? For my use case in
> > Zeitgeist I was hoping that I could completely get rid of a "Manager"
> > type of interface, and just implicitly create objects in the tree
> > whenever calls where made to them. This does not look possible as it
> > stands?
> >
> > Maybe allowing '*' as a wildcard node name in the subtree enumeration function?

I'm actually a bit wary of introducing this kind of functionality -
mainly, I guess, because it screws with the notion that a D-Bus service
export a set of objects. In particular it makes it hard to
debug/introspect the service - for example, in extreme abuses of such a
feature (not the use-case you are suggesting though), you can't really
use e.g. d-feet to get an idea of what kind of objects are exported and
known by the service.

The subtree functionality is really just for performance hacks - the
intended use is to avoid creating a huge amount of objects. For example,
one use case is export the subtree /org/foo/Project/processes/<pid>
where <pid> is, say, a UNIX process id. With the subtree handler, no
object creation over is necessary.

Anyway, your original use case does seem sound and reasonable - it
reduces overhead insofar that the client saves a round-trip to a
hypothetical Manager.CreateObject() method that would be needed if we
didn't have this. It does make it less intuitive insofar that remote
object creation is this magical thing with automatically appearing
nodes... but I guess that's fine.

> I had a stab at this myself. The wildcard idea seemed like a bad one,
> so I instead added another gboolean param to
> g_dbus_connection_register_subtree(), @is_dynamic.
> 
> If is_dynamic is TRUE then objects need not be in the enumerated list
> of objects in order to be introspected and dispatched. Pretty simple.
> 
> No matter the simplicity I still managed to screw up one of the unit
> tests. I will fix it and add some specific tests for the dynamic case
> if you give the "go" for this David.

Sounds good to me. I'd prefer a GDBusSubtreeFlags flag enumeration with
a G_DBUS_SUBTREE_FLAGS_DISPATCH_TO_UNENUMERATED_NODES member instead of
@is_dynamic. Just for future proofing and all. Maybe it would also be
nice to pass a "gboolean enumerated" to @introspect and @dispatch that
indicates whether the node was enumerated (or not).

> PS: And thanks for nice readable and commented code David!

Hey, thanks for trying it out and providing feedback!

Thanks,
David