[Telepathy-commits] [telepathy-spec/master] Annotate a few problems and whether they have been solved for dispatching

[Simon McVittie]

20080610172255-53eee-d870f8e2dac2809a21f7ff24310396b5e9224e39.gz
---
 doc/dispatch.txt |   14 +++++++++-----
 doc/request.txt  |    8 ++++----
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/doc/dispatch.txt b/doc/dispatch.txt
index c1b073a..1f70a5b 100644
--- a/doc/dispatch.txt
+++ b/doc/dispatch.txt
@@ -30,7 +30,7 @@ Current implementation, _`dis1impl1`::
     When the tray icon is clicked, Mission Control continues processing
     filters and eventually dispatches to the channel handler
 
-Problems:
+Problems addressed by proposed implementation:
 
 * We want a logger (which might be in a separate process) to be told to
   handle incoming text channels. This may require that:
@@ -85,7 +85,7 @@ Proposed implementation:
 * The chat UI is a Client and a Client.ChannelHandler (selected in an
   implementation-specific way)
 
-Problems remaining:
+Problems remaining (FIXME):
 
 * How do we ensure that the logger has started before the channel handler
   starts acknowledging messages? I don't like the idea of having channel
@@ -124,6 +124,8 @@ Alternative implementation, _`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
@@ -144,7 +146,7 @@ Current implementation in Empathy, _`dis3impl2`:
 
 * As a result, the new message is indistinguishable from a new channel (dis1_)
 
-Problems:
+Problems with dis3impl2_:
 
 * Not associated with the previous chat session, although this could be fixed
   with "conversation thread IDs" as in req27_
@@ -163,7 +165,7 @@ Alternative implementation, _`dis3impl3`:
 * in practice this would give basically the same UI as for dis3impl2_, but
   without actually closing the channel
 
-Problems:
+Problems with dis3impl3_:
 
 * if it is desirable to tell the remote user that the window has been closed,
   the CM can't know
@@ -176,10 +178,12 @@ Incorrect implementation, _`dis3impl1`:
 
 * The new message causes the chat window to pop up, possibly stealing focus
 
-Problems:
+Problems with dis3impl1_:
 
 * Focus stealing is likely
 
+Proposed implementation: keep dis3impl2_
+
 _`dis4`: Incoming 1-1 text chat thread
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/doc/request.txt b/doc/request.txt
index 0b616cd..c0a31a2 100644
--- a/doc/request.txt
+++ b/doc/request.txt
@@ -1073,7 +1073,7 @@ and (Text, ROOM, foo) correspond 1:1. Activity discovery is done out-of-band
 using OLPC-specific extensions, although we'd like to make some of it
 more standard (mainly invitations).
 
-Problems:
+Problems addressed by proposed implementation:
 
 * we don't want Tubes channels in their current form, since dispatching them
   is likely to be a bit of a nightmare if we can't rely on OLPC assumptions;
@@ -1156,7 +1156,7 @@ Current implementation (NMC 4.x)::
         cancellation fails
         the UI is asked to handle the channel
 
-Problems:
+Problems (FIXME):
 
 * 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
@@ -1174,8 +1174,8 @@ point, and it takes a couple of minutes for him to walk towards one.
 Naive implementation: the request is a method call, the request being
 satisfied is a response
 
-Problems: the D-Bus method call will time out after around 25 seconds
-unless special action is taken
+Problems addressed by proposed implementation: the D-Bus method call will
+time out after around 25 seconds unless special action is taken
 
 Proposed implementation: the ChannelDispatcher creates a request "cursor"
 object for the duration of the request
-- 
1.5.6.5