[Telepathy] [Bug 14606] After a channel is closed, you can't tell who was in it (the " missed call from, er, someone?" bug)

[bugzilla-daemon at freedesktop.org]

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2008-02-26 05:53:26 PST ---
Perhaps we're approaching this from the wrong direction. It might be
instructive to consider Text channels (instant messages).

A Text channel maintains a queue of unacknowledged messages. UIs are expected
to acknowledge the messages when they have displayed them to the user.

We have previously suggested that on protocols where you can tell, the other
participant leaving a 1-1 chat might cause a Closed event on the channel.
However, on reflection, this is clearly wrong - when the channel has been
closed, the unacknowledged messages are lost. We now (implicitly) suggest using
the Chat_State_Gone state on the ChatStates interface to signal that the other
participant has gone; this leaves the channel open and available for
inspection, until the UI closes it.

(Tangentially, I suggest we go further here, and disallow closing a Text
channel if it has any unacknowledged (pending) messages, rather like the way
Group channels can only be deleted if they are empty.)

The high importance of *this* bug comes from the fact that missed calls are
considered to be "messages" that should not be lost under any circumstances.
With that in mind, why don't we go with a solution that parallels text
channels? Instead of issuing a Closed event on the StreamedMedia channel, we
can just signal that the other participant has left, by issuing a
MembersChanged event. UIs and/or Mission Control can inspect the channel at
their leisure.

This still leaves us with the problem that when the UI or Mission Control
inspects the channel, it can't find out who called. If the channel is still
around, however, we can fix that easily with an InitiatorHandle property or a
GetInitiatorHandle method.

There is one remaining problem, which is that when the Connection goes down due
to network error, all the Channels necessarily die (and handle validity goes
out of the window). This could also cause loss of IMs in the Text API. This is
harder to fix, although we could address it by keeping the Connection around in
some sort of "zombie" state (DISCONNECTING?) until all channels have been
"acknowledged" with Close(), at which point perhaps the Connection would
perhaps move to DISCONNECTED.


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