[Telepathy] TpHandler

[Danielle Madeley]

On Tue, 2009-11-24 at 12:31 +0000, Simon McVittie wrote:
> 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 :-)

So there doesn't seem to be a lot of code here. What am I looking at in
particular?

> 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.

So, following on from discussion today, the consensus was that this is
fundamentally a pointless requirement and should be dropped from the
spec. Mission Control should union the channels together itself. This is
really the only way things can be done, because there is no easy way for
the diverse Handlers that might exist to generate a union of channels
(e.g. a client might have both tp-glib and tp-python in it -- plugins
make this possible; or might use TpHandler and a hand-tooled Handler).

This has been filed as
https://bugs.freedesktop.org/show_bug.cgi?id=25286

Passing channels off from a transient Handler to a more long-term
Handler can be handled internally by the application. I think a

        GList *tp_handler_get_handled_channels (TpHandler *) and
        tp_handler_handling_channel (TpHandler *, TpChannel *)

will suffice here. You can copy the channels across before disposing of
a Handler.

> 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.

I agree this didn't make sense. I've removed it.

A warning could be added for TpChannel objects that are completely
unreffed when the Handler is disposed, because that means they weren't
closed or passed to someone else.

> 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.

Can't you use the unregister_object method? This seems like it is beyond
the scope of the TpHandler, which provides no registration support
itself.

-- 
Danielle Madeley
Software Developer, Collabora Ltd.                  Melbourne, Australia

www.collabora.co.uk