org.fd.DBus.Introspectable.EnumerateObjects()

[David Zeuthen]

Hey,

On Wed, May 12, 2010 at 7:44 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
>  org.fd.DBus.Introspectable.EnumerateObjects(in s interface, out ao paths);

If we do this, I'd like it look be a bit more complicated

 EnumerateChildren(in as interfaces,
                  in i flags,
                  out a(sa{sv}) children);

where

1. if interfaces is the empty array, return all interfaces
   (like your empty string)

2. only returns names of the nodes below the path this is invoked on
    (same rules as in introspection XML).

3. if FLAG_INCLUDE_PROPERTIES (let's say it's bit 0) is set, do
   not include properties.

   Otherwise include org.fd.DBus.Properties properties (if any) in
   the requested interfaces (same rules as GetAll()).

Items 1. and 2. shouldn't be controversial. Item 3 has to do with that
you typically are interested in the properties anyway. So getting all
object properties for all objects of interest in a *single* call is a
huge win I think [1].

We could also have FLAG_INCLUDE_GRANDCHILDREN or some other way to
indicate the depth we're interested in...

[1] : Especially since a typical mistake is to write code that
ping-pongs N times to load properties in a serial way....

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

Generating correct XML is pretty easy (g_string_append, basically...).
Parsing XML is much harder, though.

However, even with this new method you can't just return a "constant
string" - you still need to include the nodes in the introspection XML
just like you do today. Because otherwise it's an ABI break... (of
course, if all tools use the new interface, breaking the old isn't
that big of a deal....)

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

Right. Another thing I mentioned is that we could do a
BinaryIntrospect() method that returns a binary version of
introspection XML of some sort. You could even soup that up, for
performance, to take a flag parameter to indicate whether you want
nodes, interfaces or both. Or something like that. </handwave>

> 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?

It would.

Cheers,
David