Short lived, or "private", objects on the bus

Havoc Pennington hp at
Fri May 18 07:43:22 PDT 2007


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.


More information about the dbus mailing list