Short lived, or "private", objects on the bus
Havoc Pennington
hp at redhat.com
Fri May 18 07:43:22 PDT 2007
Hi,
Objects can have any lifecycle policy you want. The most common ones are:
- infinite (global singleton for example)
- tied to the apps using them (you track when apps using them
disconnect, and if they all disconnect you can nuke the object)
- lease (you destroy the object after it has not been used for a period
of time)
- tied to one app using the object, with explicit destroy (i.e. if the
app disconnects without destroying, you clean up; but the app is
encouraged to explicitly destroy before that, if it's done with
the object)
Bad lifecycle policies:
- *only* explicit destroy - this is unreliable and unsafe, because
the app that is supposed to destroy may fail to do so due to
bugs, crashes, etc.
- reference counting - unreliable and unsafe for the same reason
- infinite, for objects that there can be an infinite number of
(e.g. a search result object created dynamically should probably
not just be infinite)
Your API docs/spec basically have to spell out one of these policies for
each object, just as a C API spec would have to.
Using an object path should not imply anything about the lifecycle
policy. In particular if a random app that didn't ask for the search
result starts using it (which seems unlikely), then I would say all of
the above policies are still reasonable and feasible.
Havoc
More information about the dbus
mailing list