Bug 16544 - using threading to link conversations over time
Summary: using threading to link conversations over time
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: unspecified
Hardware: Other All
: lowest enhancement
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard: speculative, semi-wontfix
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-27 04:36 UTC by Simon McVittie
Modified: 2019-12-03 20:17 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Simon McVittie 2008-06-27 04:36:15 UTC
We've decided to defer more discussion of message threading (like in XEP-201) until after the "requestotron" (property-based channel requesting interface) is finished, since it seems to be quite hard.

Issues include:

* how aggressive should UIs be about allocating new thread IDs? If you close an Empathy chat window/tab and open a new one to the same user, is it a different thread?

(Sjoerd thinks it probably isn't. Use-case: Sjoerd opens a chat window to talk to Simon, sends the message "how do you make sbuild work?" (not expecting an immediate response), and closes the chat window. He then realises he has something more to say, opens a new chat window to talk to Simon, and sends the message "never mind, worked it out".)

* should multiple threads really be represented by parallel channels, or should they be messages tagged with thread IDs within one channel? (The Messages interface can do this)

* should threads in a MUC chatroom be as separate as threads in a 1-1 chat are?
Comment 1 Simon McVittie 2009-11-04 09:42:10 UTC
No discernable demand.
Comment 2 Simon McVittie 2010-11-02 09:30:48 UTC
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?
Comment 3 GitLab Migration User 2019-12-03 20:17:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/12.


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.