| Summary: | After a channel is closed, you can't tell who was in it (the "missed call from, er, someone?" bug) | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | tp-spec | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | major | ||
| Priority: | high | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
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. ++ for the "zombie" state (DISCONNECTING) on connections and using the
Chat_State_Gone state on channels
> 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.
We have the same problem if the user joins a chatroom and then leaves it. In
this case the initiator is not the only handle the UI may want to inspect, so I think InitiatorHandle or GetInitiatorHandle are not generic enough.
I suggest to add a method connection.HoldNewChannel()->nothing so that the UI
is guaranteed to be able to inspect all handles of the group until the UI call
connection.ReleaseNewChannel(o: channel)->nothing. The HoldNewChannel method
call must be done before receiving the NewChannel signal.
Partially fixed by the Requests interface, which implements Rob's first suggestion from the initial bug report. Do we consider Requests to have solved this bug? Should we close it? Answers on a postcard... Conclusion: yes, this was fixed by Requests. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
After a group channel is closed, handles that were previously in that channel may have become invalid, so you can no longer inspect them. This leads to the following failure: CM: NewChannel: /foo/bar, channel type StreamedMedia, handle type 0, handle 0 client: foobar = Channel("/foo/bar") client: foobar.GetMembers() CM replies to GetMembers: [42] CM: /foo/bar Closed client: InspectHandles([42]) CM replies to InspectHandles: InvalidHandle If the group channel closes quickly enough, you can even get this: CM: NewChannel: /foo/bar, channel type StreamedMedia, handle type 0, handle 0 client: foobar = Channel("/foo/bar") client: foobar.GetMembers() CM: /foo/bar Closed CM replies to GetMembers: no such channel In private mail, Rob wrote: """ One idea for fixing this particular one might involve adding a richer/alternative channel request/notification interface, where RequestChannel method and NewChannel signal have a dictionary which they can use to request/notify of properties belonging to the channel. When the signal is extensible, extra items like the call initiator's handle, and its string value, could be included in this dictionary. I don't really see a clean way to fix it by playing games with handle validity or reference counting or so, unless we added a way for a bus client to "subscribe" to handles, so that it owned a references to every new handle and was notified of them being created, and then could choose to use the value or to unref the handle. Seems a little mad though. """ Rob's first suggestion would fix this problem; his second would fix the first example but not the second.