[Telepathy] TpHandler

[Simon McVittie]

On Tue, 24 Nov 2009 at 10:40:00 +1100, Danielle Madeley wrote:
> It might be
> possible to have a "close-channels-on-dispose" property that can be set
> to FALSE, combined with a tp_handler_track_channel() method call so that
> a temporary Handler can pass a channel off to the real Handler, but in
> general things will work correctly.

Please look at telepathy-qt4, whose Tp::AbstractClientHandler class implements
telepathy-spec without its users having to jump through hoops, before going
further with this class. We've designed many of the subtleties once already,
there's no need to do it all again :-)

(I realise you don't like the necessity to subclass, and I can see why -
plain callbacks are much more natural in GObject than they would be in C++ -
but I think the rest of the design is equally applicable to GObject.)

Specifically, the HandledChannels list in AbstractClientHandler is the union
of the HandledChannels lists of all the Handlers that share a unique name on
the bus - which is exactly what the spec says to do, for the very reason you
point out.

The spec considers a handler to be handling the channels as long as the
*unique* name exists, and this is what MC implements (the channels are only
closed by MC when the unique name vanishes, i.e. when the client crashes).
This does introduce a slight inconsistency, since MC crash-recovery will only
consider channels to be handled if the handling process has at least one
Handler that says it still has them.

I'm not sure whether it makes sense to auto-close the channels when the
Handler GObjects are all disposed or not. If it does, I would like this to be
viewed as an "emergency rescue" feature, possibly accompanied by a g_warning,
rather than normal behaviour.

There should be some way to remove the GObject from the bus without waiting
for it to have no refs (using the method I added in dbus-glib >= 0.82 for
the actual removal) - after various bad experiences in Gabble, I'd like to
avoid relying on side-effects of object destruction for application logic.

    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20091124/bf4ae879/attachment.pgp