Getting a list of object paths for a service ?

[Havoc Pennington]

On Sun, 2005-10-02 at 23:06 +0100, Daniel P. Berrange wrote:
> 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.

Not too shocking, I don't see it in the docs ;-) would be worth fixing.

This is the purpose of register_fallback(), basically. Otherwise you'd
only have register_object_path().

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

I like that also.

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

A simple policy would be that unregister_object_path doesn't do
batching, but custom implementations using register_fallback could do
batching if appropriate. Usually when mass-creating or mass-deleting a
bunch of flyweight objects.

Hmm, the fallback handler will have to implement emitting the signal so
we'd need a function call for that probably...

Havoc