[Bug 16544] using threading to link conversations over time

[bugzilla-daemon at freedesktop.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Message threading spec      |using threading to link
                   |                            |conversations over time
  Status Whiteboard|semi-wontfix                |speculative, semi-wontfix

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-11-02 09:30:48 PDT ---
Bug #31329 is the "collaborative app" case. The other possible use for
threading is to associate temporally disconnected conversations:

_`req26`: Recovering from disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo is talking to Juliet using text chat, but is disconnected due to network
instability. After reconnecting, he wants to keep using the same window to
talk to Juliet.

A solution for this use case should work correctly (and result in
a single channel) if there is a "mid-air collision" with Juliet doing the
same thing, with Juliet sending messages to Romeo while he is still
offline (on store-and-forward protocols like XMPP), or with Juliet
recovering from Romeo's disconnection as per req28_ (on protocols that
do not allow offline messages).

(Recovering from a connection manager crash is equivalent to this.)

:New vs. existing:
    ???
:Definition of channel identity:
    ChannelType is Text, TargetHandleType is CONTACT, TargetHandle is juliet,
    ThreadID is the same as before

Current implementation: same as req1_

Problems addressed by proposed implementation:

* the two conversations are unrelated (Juliet cannot distinguish
  between this case and req1_)

Proposed implementation (with a new Chan.I.Thread)::

    Romeo's chat UI (or incoming message database) automatically saves the
    ...Channel.Interface.Thread.ThreadID property of the old channel

    Disconnect/reconnect occurs

    Same as req1, except that ThreadID is included in the request

Problems remaining:

* What should the CM do if the desired thread ID cannot be used for some
  reason?

* There is a potential race, req26b_

Resolution: defer the threads spec til later,
https://bugs.freedesktop.org/show_bug.cgi?id=16544

_`req26b`: potential race
^^^^^^^^^^^^^^^^^^^^^^^^^

The same as req26_, but before Romeo's client can open the replacement
channel, Juliet sends him a message, thus opening a new channel. (This
is really a dispatching problem, but is closely related...)

The desired behaviour is that the same handler receives the channel.

Imagine that Romeo has both Kopete and Empathy installed, and Empathy
is the default, but Romeo is using Kopete to talk to Juliet.

Naive implementation: either the race is won by the request for a
replacement channel (and Kopete gets it) or it's won by Juliet's message
creating a new channel (and Empathy gets it).

Too-clever implementation: in principle, there's nothing to stop the
channel dispatcher remembering that a channel handler has lost a channel,
and using that as input to its handler-choosing heuristic

_`req27`: Resuming a conversation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo chooses a past conversation with Juliet in a log browser and wants
to resume it. (The definition of threading in XMPP expects that this is
possible.)

:New vs. existing:
    Existing channel preferred, new channel acceptable
:Definition of channel identity:
    ChannelType is Text, TargetHandleType is CONTACT, TargetHandle is juliet,
    ThreadID is the same as before

Current implementation: same as req2_

Problems addressed by proposed implementation: Juliet cannot distinguish
between this case and req2_

Proposed implementation: same as req26_, except that it resembles
req2_ instead of req1_ (i.e. no SUPPRESS_HANDLER flag)

Problems remaining: same as req26_ (including a potential race, like req26b_)

Resolution: defer the threads spec til later,
https://bugs.freedesktop.org/show_bug.cgi?id=16544

_`req28`: Recovering from other's disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Juliet is talking to Romeo using text chat when Romeo is disconnected
due to network instability. The protocol is one that does not
allow offline messages to be sent, like IRC. After Romeo reconnects, Juliet
wants to keep using the same window to talk to him.

A solution for this use case should work correctly (and result in
a single channel) if there is a "mid-air collision" with Romeo doing the
same thing, or with Romeo recovering from disconnection as per req26_.

(Recovering from Romeo's connection manager crash is equivalent to this.)

Current implementation: Juliet's text channel does not close, but
she cannot send messages. When Romeo reconnects, because of 1-1 chat
uniqueness, Juliet's client continues to use the same channel and there
is no disconnection.

Proposed implementation: Juliet's client continues to use the same channel

Problems remaining: how do we ensure that?

-- 
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.