[Bug 30617] TpChannel: high level API to close/leave channel

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjoerd at luon.net

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-04 04:27:29 PDT ---
I don't know how this method should relate to Call channels, which distinguish
between hanging up and closing the channel; if you Close() a Call channel,
that's assumed to be "unclean shutdown", e.g. from Mission Control closing an
undispatchable channel or cleaning up after a crashed Handler. Sjoerd, what do
you think?

We should probably have two methods, close_async and leave_async, with the
former wrapping the latter behind-the-scenes, and document leave_async as being
intended for use with chatrooms etc.?

(In reply to comment #1)
> Do we want to check if TP_IFACE_QUARK_CHANNEL_INTERFACE_GROUP is implemented
> before calling RemoveMembers (as MC does)?
> If yes, should this function assume that TP_CHANNEL_FEATURE_CORE is prepared on
> the object?

I don't think waiting for Core is desirable. I think the logic should go
something like this:

* if we know the Interfaces already, and Group is not among them, Close
* else if the reason and message are trivial, Close
* else RemoveMembers; if that fails, and the channel has still not been
invalidated, Close instead

This means if the channel isn't prepared *and* we don't know its immutable
properties, we might try RemoveMembers on a channel that later turns out not to
have been a Group, but trying RemoveMembers is no slower than getting the
interfaces, so, no problem.

> What happen if user passes a non empty message or a not none reason on a
> channel not implementing Group? Operation fails? We fall back to Close() and
> succeed ? We fallback and fail?

Fall back and succeed, I think. The important thing is that we left.

Also, if the channel is invalidated before we've finished and the method call
fails, we should DEBUG() the failure reason, and succeed anyway - again, the
important thing is that we left. The only way "leave" can fail should be if
Close() failed and the channel remained open (e.g. non-empty Group).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.