[Telepathy] Uniqueness of objects

[Xavier Claessens]

Hi,

It's a bit late so I could be missing something, but what about that:

1) Change the meaning of HoldHandle to mean refcount++
2) Change the meaning of ReleaseHandle to mean refcount--
3) Each call that return a handle (RequestHandles, GetAllMembers, etc)
make a refcount++ so the caller is responsible to call ReleaseHandle.
4) Handles spontaneously created and emitted in a signal have a "weak
ref" that expires after X min if not reffed by HoldHandles (or
GetMembers, etc). Where X is big enough for a dbus round-trip.

Of course Telepathy libraries have to hide all that stuff from clients.

Xavier Claessens.

On mar, 2008-09-30 at 21:01 +0100, Simon McVittie wrote:
> I'm starting to wonder whether we need to *guarantee* that certain
> objects are unique, because of some reference-counting corners we've
> painted ourselves into. Handles are held per connection to the bus
> daemon, therefore we can never safely release any handles unless we can
> refcount them per (DBusConnection, Telepathy Connection) tuple.
> 
> I think it's reasonable for us to forbid calling ReleaseHandles from
> user code without going via a Telepathy library, since that can't possibly
> work (unless the libraries *never* release handles, which seems undesirable).
> Accordingly, we should conceal ReleaseHandles from the telepathy-glib
> documentation.
> 
> I don't think we can make TpConnection the object that has exactly one
> instance per (DBusConnection, Telepathy Connection), because
> TpConnection is subclassable. If you construct a TpConnection subclass
> MyConnection while a TpConnection exists for that (DBusConnection,
> TelepathyConnection) pair, that mustn't be a problem.
> 
> So, we need some sort of handle-referencing helper (it needn't be
> visible to users, TpConnection could use it internally).
> 
> Hmm... but thinking about it, even if we refcount handles in telepathy-glib,
> this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a
> connection, since neither library will be willing to call into (= depend on)
> the other in order to update the shared handle cache :-( Any ideas?
> 
>     Simon
> _______________________________________________
> Telepathy mailing list
> Telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy