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

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

2009/10/28 Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>:
> 2009/10/27 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 :-)
>
> They did :-)
>
> Attached is a series of patches (0001 should be identical to my
> previous) implementing what you describe, except adding the gboolean
> enumerated arg to @introspect and @dispatch. I will get around to
> that.
>
> The failing unit tests I described was really just me b0rking up the
> linking between some installed gdbus components and my devel version.
> I have them running now[1] and I added some testing for the dynamic
> objects as well (see 0003).

Some more tests to go with the other patches attached.

I mulled a bit over your idea about passing a gboolean to @introspect
and @dispatch. I am not sure I think it is such a good idea. What's
the motivation? It can potentially save one a two looksup in a hashmap
or some other data structure, but nothing really big. And I worry that
this might be racy in nature. The @introspect and @dispatch functions
would certainly have to be called from inside the same critical region
(enclosing the @enumerate call as well). Then we'd have a mutex grab
instead of two lookups...

Another thing is that the boolean arg also seems strangely out of
place in a way that I can't put my finger on... So unless you insist
on having it I wont do the extra arg right now.

-- 
Cheers,
Mikkel