[Telepathy] Requestotron use-cases, part 5 (more requests)

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Jun 5 06:34:41 PDT 2008 

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

On Tue, 29 Apr 2008 at 17:31:22 +0100, Simon McVittie wrote:
> HTML at <http://people.collabora.co.uk/~smcv/request.html>, Darcs branch
> at <http://monkey.collabora.co.uk/tp-spec-smcv-usecases> (it's written
> in reStructuredText), current text later in this email for easy quoting.

I've now merged the first 4 batches of use cases into the main
telepathy-spec repository, and I'm about to do the same with some more.

We've also been thinking about the implementation, which is starting to
take shape in telepathy-spec branches on Merge Monkey. All comments
welcome.

Here are some more request use-cases from the mailing list and from further
discussion. More dispatch use-cases (part 6) will follow in a moment.

diff -rN -u -p old-tmppMZkwt/doc/request.txt new-tmppMZkwt/doc/request.txt
- --- old-tmppMZkwt/doc/request.txt	2008-06-05 13:41:23.962169888 +0100
+++ new-tmppMZkwt/doc/request.txt	2008-06-05 13:41:23.994171888 +0100
@@ -59,6 +59,65 @@ that may be ongoing.
 Current implementation: impossible, even in protocols supporting
 conversation threads, because the spec can't represent them
 
+_`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.
+
 Outgoing VoIP call
 ------------------
 
@@ -171,6 +230,53 @@ Current implementation: same as req5_
 
 Problems: same as req5_
 
+_`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
+
 Joining a named chatroom by request
 -----------------------------------
 
@@ -327,6 +433,71 @@ Problems:
 * Determining whether we already have a channel to Juliet becomes harder
   than in req1_
 
+_`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)
+
 _`req14`: Ad-hoc chatroom from chat UI
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -533,5 +704,54 @@ _`req25`: Existing UDP/TCP client/server
 Romeo offers Mercutio and Benvolio access to an OpenArena server running
 on his local computer.
 
+Failures and other exceptional cases
+------------------------------------
+
+_`req34`: failing to send a text message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Romeo opens a text channel to Juliet to send a message, but Juliet's server
+is down and Romeo's server signals failure. (This is mostly applicable to
+decentralized protocols like XMPP and SIP.)
+
+Current implementation::
+
+    the message is sent
+    SendError (and soon DeliveryReporting) report the failure
+    the channel remains open
+
+_`req35`: failing to make a call
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Romeo makes a VoIP call to Juliet, but Juliet's server crashes and failure
+is signalled.
+
+Current implementation::
+
+    Juliet is removed from the Group interface, with an error for the reason
+    the StreamedMedia channel closes
+
+_`req36`: Cancelling outgoing call
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Juliet starts a VoIP call to Tybalt, but then thinks better of it and
+cancels the call before the channel has actually been opened.
+
+Current implementation (NMC 4.x)::
+
+    UI calls mission_control_cancel_channel_request()
+
+    if dispatching of the channel has already begun:
+        cancellation succeeds
+    else:
+        cancellation fails
+        the UI is asked to handle the channel
+
+Problems:
+
+* In NMC 4.x the UI cannot distinguish between the channel that it no longer
+  cares about and should close/refuse (this use case), and a channel requested
+  by another process but handled by it (req5_)
+
 ..
   vim:set sw=4 sts=4 et:
-----BEGIN PGP SIGNATURE-----

iD8DBQFIR+toWSc8zVUw7HYRAnqAAJ0WF587tgKe8nOWtMOcpaktDbtU8wCeI8ML
XjtFhIzYUEoQsFIPguuvo+s=
=bjmg
-----END PGP SIGNATURE-----

More information about the Telepathy mailing list