[Bug 24939] Interface for upgrading chats/calls to multi-user

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24939





--- Comment #6 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2009-11-13 11:22:09 PST ---
Interaction with approvers and MC is tricky. Because C2/C4 are new channels,
they go through the normal dispatch process.

For Bob, we'll usually want the UI that requested the channel C4 to be the one
handling it. This suggests that the yet-to-be-defined upgrade API should be to
call CreateChannel or EnsureChannel, and get normal MC behaviour; approvers
will be bypassed because Requested=True, which is appropriate.

For Alice things get more complicated, because depending on protocol behaviour,
she might be in either Members or LocalPending in C2 (in XMPP she'll be in
LocalPending, but in MSN/Skype she'll be forced into Members immediately,
because in the underlying protocol, she is in the switchboard or equivalent
already).

There are three interesting UI policies that I can see:

* Treat the channels like any other new channel, complete with Approvers. Easy
to implement.

* Automatically pick up and accept the channels. This can be done by having an
Observer in the chat UI, which Claim()s any channel that is a continuation of a
channel that it is already handling, then accepts the invitation if necessary;
or even by having an Observer per channel being handled, which claims
continuations of exactly that channel. However, there's a race condition here
which needs to be solved: Bob might start talking to Alice, then immediately
invite Chris, before Alice's chat UI has set up its Observer (or perhaps even
before Alice's chat UI has *started*).

* Apply the first policy to channels where Alice is in LocalPending (XMPP) and
the second to channels where Alice is in Members (Skype?).


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