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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
