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?
No discernable demand.
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?
-- 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.