DBus Object Paths and Refcounting

[Havoc Pennington]

Hi,

Ryan Lortie wrote:
> This would be really really cool, but maybe it's just completely
> unimplementable.  To be quite honest, I haven't thought too much about
> it :)
> 
> Any comments?
> 

I have some posts in the archives that wax philosophical about the 
reasonable approaches to object lifecycle. (e.g. leases and "keep track 
of who is using me" are two)

There are a couple issues with just naively doing refcounting:
  - you end up firing tons of messages around to ref/unref
  - you get tons of leaks if the refcountee does not track
    when refcounter disconnects without unref'ing

In practice I think the best thing might be convenience API for "keep 
track of who is using me" - something I proposed in that "gbus" thingy I 
posted.

The patterns I think are most common:
  - permanent/never-die objects
  - app-specific API that involves "registering" a client or context,
    which effectively allocates resources, which are freed if the
    connection that registered disconnects
    (i.e. "track who is using me"). But a "manually unregister"
    call is usually available also for clients that want to clean
    up but not disconnect.

The second one could be called "alloc/free with the server freeing if 
the owner disconnects" - refcounting here could be *in the client 
process*, there's no need to put it on the server side since the client 
is the only owner/user of the object.

I think it's good for at least lower layers of dbus to be agnostic on 
the lifecycle policy, but I think convenience API (which we need much 
more of) could offer shortcuts to useful patterns and the spec might 
even spell out how to do some of the patterns in a standard way.

Havoc