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

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

2009/10/27 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.

Not to mention the built in race condition you have if the exported
objects can also be deleted via the manager. All client apps would
have to precede all calls to an object by a Create() message (and it
would still be racy). Anyway, enough about this :-) I think it is
probably a fragment of my REST/web background where such patterns are
more common.

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

That sounds like a better idea. I'll have another stab at this tonight
if the kids allow me :-)

-- 
Cheers,
Mikkel