Getting a list of object paths for a service ?

[Havoc Pennington]

Hi,

We should get this sorted out pretty quickly ... or at least be sure
it's in TODO.

The "disown bus name" change needs to go in TODO also if it isn't...

A general comment, the current stuff was designed so that each object
lists its own children, vs. the service knowing about all objects.
The object registration stuff in libdbus is only intended for
convenience for simple objects, and to register "roots" where the root
handler might track child objects in its own way (this is the
register_fallback). For example, if you did a thing to export all
GtkWidget in a process in a tree of object paths, you could just
register one handler with libdbus, say at /org/gtk/widgets. 
This handler would then map each toplevel window to a name:
 /org/gtk/widgets/window1
 /org/gtk/widgets/window2

Then each child of the toplevel:
 /org/gtk/widgets/window1/vbox1
 /org/gtk/widgets/window1/vbox1/button2

or whatever. In fact I thought I implemented that once, but maybe I just
thought about it. DCOP has a thing like it.

Anyway, right now Introspect is delegated to each object so this works.
We would need to preserve that, one way would be to extend
DBusObjectPathVTable to have a list_objects function maybe.

On Thu, 2005-09-29 at 21:37 +0100, Daniel P. Berrange wrote:
> 
>    org.freedesktop.DBus.Exporter
> 

I think there's probably a better name, like ObjectRegistry or
ObjectManager or something. Suggestions welcome...

> Containing a method
> 
>     ListObjects (out ARRAY of STRING exportedObject )

It might be nice if this took a "root" argument?

Maybe it should work like readdir(), it only returns immediate children,
it doesn't recurse the whole tree. You could still quickly recurse
everything by doing:
  roots = ListObjects("/");
  for (r in roots)
    async_list_objects(r); // fire off async list requests

Then as the async requests come back, fire off more async requests. By
doing it all in parallel it'd be nice and fast. Of course the current
bus implementation will serialize it all anyhow, but you do avoid round
trips this way which would allow it to be fast even over a high-latency
connection.

Another approach is something like:
 NotifyObjects(in STRING root);

which emits the ObjectRegistered signal with a recipient field (rather
than the normal broadcast) for each object under the root. This lets you
just write the ObjectRegistered signal handler, then call NotifyObjects,
instead of handling ObjectRegistered in one place and the ListObjects
reply in another place.

> And two signals to notify when objects are registered/unregistered
> within a service:
> 
>     ObjectRegistered (in STRING objectPath)
>     ObjectUnregistered (in STRING objectPath)

This is potentially pretty inefficient. Imagine a case like a
spreadsheet, each cell is a dbus object, but there isn't really a C++ or
Java object per cell; the spreadsheet just dynamically maps an object
name like "A:21" to column A row 21.

One possible compromise is that you only get a single signal when the
list of objects under a given root has changed. i.e. if 
foo/bar and foo/baz both appear, I get one signal "ChildrenChanged(foo)"

Then if someone cares about that node, they can call ListObjects.

Another approach is some kind of subscribe-to-change-notifications
system, but that will put a fair bit of new complexity in libdbus.

>     print "Service: ", $service->get_service_name, "\n";

Remember we dropped "service name" in favor of "bus name"

Havoc