mzqohf at 0pointer.de
Wed May 12 16:44:15 PDT 2010
Since we are all busy discussing spec additions and it is so much fun,
here's another one I'd really like to see implemented, and I am willing
to put a patch together for, if we can get some agreement on this:
I'd like to have an additional method call in the Introspectable interface:
org.fd.DBus.Introspectable.EnumerateObjects(in s interface, out ao paths);
What does this do?
It will basically return all child objects of the object called that
implement the specified interface. If the interface string is the
empty string, then it will return ALL child objects, regardless of the
interfaces they implement.
1) The current XML introspection data covers this use case already,
however I really dislike the fact that the otherwise completely static
XML blurb includes the dynamic node information. I'd vote for keeping
the static and dynamic data seperate. This allows programs to simply
return a constant string in the introspection data, that matches 100%
with the one stored in /usr/share/dbus/interfaces. This is especially
good because the XML data tends to get big, and writing a completely
correct XML serializer is not a trivial job.
2) Almost every non-trivial existing D-Bus service implements a
function like this in one way or another. It would be good to unify
this. Of course, there will always be services that need specific
enumeration functions, for example because they need more complex
filtering or additional object data returned. However, I'd argue that
providing the minimal filtering possible with the interface name is
a good building block for the majority of uses.
Is this recursive?
Well, I guess by default an object should only return those child
objects that are its immediate children, however, much like with the XML
introspection data it should be possible to return grandchildren and
objects further down the hierarchy as well, if that is a good idea in
the specific case. We could even add an annotation in the
introspection that encodes whether the call is recursive or not.
What about the old XML introspection node info when we introduce this?
Already, the XML intrsopection node info is optional. An object
implementing EnumerateObjects() should probably drop the node data
from the XML blob, however that is not mandatory. Applications such as
d-feet should be fixed to call EnumerateChildren() when building the
Where from there?
David suggested we should have signals for notifications for children
coming and going, too. I agree with that but I'd first like to see
some agreement here about the basic approach. Of course, as soon as we
get those signals we could make d-feet a lot more usable because it
could update its tree live. Wouldn't that be awesome?
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus