org.fd.DBus.Introspectable.EnumerateObjects()

[Lennart Poettering]

Heya!

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.

Why?
  
  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
  introspection tree.

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

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4