2009/10/28 Mikkel Kamstrup Erlandsen <mikkel.kamst...@gmail.com>: > 2009/10/27 Mikkel Kamstrup Erlandsen <mikkel.kamst...@gmail.com>: >> 2009/10/27 David Zeuthen <da...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list