[Telepathy-commits] [telepathy-spec/master] dis2: improve clarity of text

[Simon McVittie]

20080625155730-53eee-880b036bfb1bd6b769ed932af8249eb76105f9c4.gz
---
 doc/dispatch.txt |   22 ++++++++++++----------
 1 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/doc/dispatch.txt b/doc/dispatch.txt
index a5e3a17..2133fe1 100644
--- a/doc/dispatch.txt
+++ b/doc/dispatch.txt
@@ -90,12 +90,12 @@ _`dis2`: Incoming 1-1 text message
 
 Juliet receives a message from Romeo after a pause in their conversation.
 
-Current implementation: it arrives in the Text channel
+Current implementation, _`dis2impl1`: it arrives in the Text channel
 
 Problems:
 
 * If Juliet's chat UI has crashed, the message is (as currently implemented)
-  lost forever
+  lost forever (_`dis2problem1`)
 
 * If the chat UI is not currently visible, as currently implemented it
   cannot necessarily use the same mechanism to notify the user that would
@@ -103,6 +103,12 @@ Problems:
   mechanism for the new-channel case (this would be fixed by dis1impl2_)
   (call this _`dis2problem2`)
 
+Proposed solution to dis2problem2_: if the the chat UI is in the same process
+as the notification mechanism, all is good - it can prod the notifier
+directly. If it's not, then it can use a D-Bus API outside the scope of this
+spec to do the same. (Avoiding premature generalization and assuming clients
+to be competent)
+
 Alternative implementation, _`dis2impl2`:
 
 * When a ChannelHandler that was handling a channel closes, the channel
@@ -110,21 +116,17 @@ Alternative implementation, _`dis2impl2`:
 
 Problems:
 
-* Incoming messages might be lost (there is a race)
+* Incoming messages might still be lost (there is a race between the channel
+  dispatcher closing the channel, and the new message coming in) so this does
+  not fully address dis2problem1_
 
-Alternative implementation, _`dis2impl3`:
+Possible solution for dis2problem1_, _`dis2impl3`:
 
 * When a ChannelHandler that was handling a channel closes, the channel
   dispatcher re-dispatches that channel (to the same or a different handler)
 
 Proposed implementation: FIXME
 
-Proposed solution to dis2problem2_: if the the chat UI is in the same process
-as the notification mechanism, all is good - it can prod the notifier
-directly. If it's not, then it can use a D-Bus API outside the scope of this
-spec to do the same. (Avoiding premature generalization and assuming clients
-to be competent)
-
 _`dis3`: Incoming 1-1 text message with window closed
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- 
1.5.6.5