Getting a list of object paths for a service ?

[Daniel P. Berrange]

On Fri, Sep 30, 2005 at 12:15:19AM -0400, Havoc Pennington wrote:
> A general comment, the current stuff was designed so that each object
> lists its own children, vs. the service knowing about all objects.

Wow, I never picked up on that detail reading the API docs before
now. I'd always thought that there was a 1-1 mapping between objects
and calls to register_object_path.

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

Yeah, clearly my suggested patch to the spec is not suitable given
the fact that child objects could be known only to their immediate
owner, not the root/service as a whole. 

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

ObjectRegistry would be my vote, since its only a way to find out
about objects, not really managing them in any conventional sense

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

Given that you suggest the possiblity of large numbers of objects (eg, one
per spreadsheet cell), it would certainly make sense to not be arbitrarily
recursive, so readdir() type semantics would be reasonable.

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

For application's functionality, recursively retrieving an entire object
tree is not likely to be a common/important task, so the overhead of having
to explicitly recurse the ListObjects() calls in the few cases where the
whole tree might be required doesn't overly concern at this time.

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

Interesting idea, would avoid alot of unneccessary broadcast traffic for 
apps which deal with large numbers of objects.

> > 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)"

Has potential to more efficient if multiple objects are created / removed 
in a short space of time / at high frequency. The service side would be 
complicated trying to decide just when / how often to send out the signals
for 'ChildrenChanged' - ie, policy for batching up object changes before 
emitting the signal.

> >     print "Service: ", $service->get_service_name, "\n";
> 
> Remember we dropped "service name" in favor of "bus name"

Had missed that bit of renaming, will amend it in the next release of 
the Perl bindings.

Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20051002/135f3696/attachment.pgp