[Bug 55391] stop MC using things deprecated in 0.20

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=55391

--- Comment #33 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #30)
> I think it is handler's responsability to do clean group leave. If MC has to
> close the channel, it can be an abrupt Close(), no?

In general I would agree with you, and indeed MC itself always uses Close() or
Destroy() as appropriate. However, this function is used to implement
mcp_dispatch_operation_leave_channels() for plugins: on the N900 and N9, it was
pretty important for a plugin to be able to terminate a StreamedMedia call as
BUSY or whatever.

You could reasonably argue that now that we have Chan.T.Call, which doesn't
(ab)use Group for call-ending, nobody should actually be using
mcp_dispatch_operation_leave_channels() any more; perhaps we should deprecate
it, and remove it in next.

(This points to a reason why plugins shouldn't share MC's factory: if a plugin
wants to terminate incoming Call channels, for instance to apply the N9's "one
active call + one call on hold" policy, it will want to use a TpCallChannel.)

At the moment, it doesn't work particularly reliably anyway (see Bug #55392).

(In reply to comment #30)
> The reason why I've made that behaviour deprecated is because it is not when
> you leave the channel that you want to start preparing more stuff. GROUP
> won't be CORE in next and will involve prepare all members TpContact...

Isn't this more like an argument for why tp_channel_leave_async() shouldn't
require or prepare TP_CHANNEL_FEATURE_GROUP? If we happen to have prepared
GROUP anyway, great, we can use the self-handle to leave; if we haven't, why
don't we just Get(SelfHandle) and then leave that way?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.