New: After a channel is closed, you can't tell who was in it ( the "misse

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

           Summary: After a channel is closed, you can't
tell who was in it
                    (the "missed call from, er,
someone?" bug)
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: high
         Component: telepathy-spec
        AssignedTo: telepathylists.freedesktop.org
        ReportedBy: simon.mcvittiecollabora.co.uk


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.


-- 
Configure bugmail: h
ttp://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Telepathy mailing list
Telepathylists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

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


Simon McVittie <simon.mcvittiecollabora.co.uk>
changed:

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




--- Comment #1 from Simon McVittie <simon.mcvittiecollabora.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: h
ttp://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Telepathy mailing list
Telepathylists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

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





--- Comment #2 from Alban Crequy <alban.crequycollabora.co.uk>  2008-04-25 04:42:25 PST ---
++ 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.


-- 
Configure bugmail: h
ttp://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Telepathy mailing list
Telepathylists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy