[Telepathy] Requestotron use-cases, part 1

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 30 Apr 2008 at 12:06:04 +0200, Xavier Claessens wrote:
> Some more possible use cases:
> 
>  - Romeo is chatting with Juliette but gets disconnected. Once the
> account gets reconnected romeo wants his chat be resumed.
>  - Romeo and Juliette are not using a protocol supporting offline
> messages and Juliette gets disconnected, once she gets back romeo wants
> its chat to resume.
> 
> Those use cases could apply to media channels too?

Thanks, I've added the following.
    Simon

_`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.)

Current implementation: same as req1_

Problems:

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

Sketch of a proposed solution: give both conversations a thread UUID, and
let the UI provide the same thread UUID when reconnecting

_`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.)

This is basically req26_ but for a different reason; I expect that the
solution can be similar.

Current implementation: same as req2_

Problems: Juliet cannot distinguish between this case and req2_

_`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 reconnecting, Juliet
wants to keep using the same window to talk to Romeo.

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

...

_`req29`: Recovering from disconnection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Romeo is talking to Juliet using VoIP, 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 ideally work correctly (and result in
a single channel) if there is a "mid-air collision" with Juliet doing the
same thing, or with Juliet recovering from Romeo's disconnection as per
req30_.

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

Current implementation: same as req4_

Problems:

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

* if Juliet calls Romeo at the same time that Romeo calls Juliet, a
  collision occurs and both calls probably fail with error BUSY

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

Juliet is talking to Romeo using VoIP when Romeo is disconnected
due to network instability. After reconnecting, Juliet
wants to keep using the same window to talk to Romeo.

A solution for this use case should ideally 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 req29_.

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

Current implementation: same as req4_

Problems:

* the two conversations are unrelated (Romeo cannot distinguish
  between this case and req4_)

* if Juliet calls Romeo at the same time that Romeo calls Juliet, a
  collision occurs and both calls probably fail with error BUSY

...

_`req31`: 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 req33_ (on protocols that
do not allow offline messages).

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

Current implementation: same as req13_

Problems:

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

* A mid-air collision is highly likely to result in two parallel
  conversations with the same members (if this is even allowed by the
  protocol)

* the interaction with offline messages is quite scary

_`req32`: 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.)

This is basically req31_ but for a different reason; I expect that the
solution can be similar.

Current implementation: same as req13_

Problems: Juliet cannot distinguish between this case and req13_

_`req33`: 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 reconnecting, Juliet
wants to keep using the same window to talk to Romeo.

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

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

Current implementation: unclear

Problems:

* A mid-air collision is highly likely to result in two parallel
  conversations with the same members (if this is even allowed by the
  protocol)
-----BEGIN PGP SIGNATURE-----

iD8DBQFIGG8qWSc8zVUw7HYRApngAKC2UB56Tkpty3r1naMUcWjCjK0riACeOqWB
RvTbMNS7TR+o5bM+NepFGq4=
=NCRK
-----END PGP SIGNATURE-----