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

[jamie]

On Fri, 2007-05-18 at 10:47 +0200, Mikkel Kamstrup Erlandsen wrote:
> Hi list,
> 
> Considering Havocs blog post http://log.ometer.com/2007-05.html, I
> have some questions about temporary/short lived objects on the bus,
> which is of concern for the xesam project[1]. 
> 
> The Setup:
> A xesam compliant search engine will spawn Search objects in response
> to application requests, and each Search object is considered
> "private" to the application requesting it (see API at [2]). Also it
> is to be expected that these Search objects are short lived in the
> sense that they wont last the entire session. Many apps will just use
> them by reading a batch of results, maybe listen for changes a a short
> while, and then discard the Search (maybe to make another one). 
> 
> The Problem:
> After the app is done using the Search object any traces of it should
> be removed. It is my understanding that you can't generally just
> remove an object from the bus since other apps might be using it.
> (Partly) because of this we use handles instead of real objects to
> represent Search objects and pass the handle to the methods of the
> Search object as you would to a C funtion in glib (fx
> org.freedesktop.xesam.search.CloseSearch(search_handle)).
> 
> The Question:
> So my question is; is this the way to do it? Or is there a clean way
> to let Search objects be real disposable objects on the bus?

I would suggest when you create a new object it returns the (unique)
object path as a string. That way each object is specific to the calling
app. It also avoids having to do match rules for signals as the signals
will be specific to the object in question.

We then have a dispose method which frees it (up to the app to do this)

I would say the only issue is how do you automatically dispose of it if
the app that created the object disconnects from the bus?

(we could store the app pid that created it and listen for disconnects
but Im not sure how this is all supposed to work and even if the
disconnect signal gives us the pid?)

jamie