[Telepathy] Requestotron use-cases, part 7 (starting to propose implementations)

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Jun 5 07:49:40 PDT 2008

Hash: SHA1

Here are a couple of last-minute changes before telepathy-spec 0.17.7,
corresponding to some discussion yesterday evening. As before, diffs below
for ease of quoting/commenting.

diff -rN -u -p old-tmpTk76QZ/doc/request.txt new-tmpTk76QZ/doc/request.txt
- --- old-tmpTk76QZ/doc/request.txt	2008-06-05 15:45:04.715086503 +0100
+++ new-tmpTk76QZ/doc/request.txt	2008-06-05 15:45:04.751088753 +0100
@@ -235,6 +235,9 @@ Problems:
 * Finding out whether a channel containing juliet's handle exists is
   needlessly laborious
+Resolved problems:
 * Unless the VoIP UI keeps a table of (handle => channel) (which can't
   necessarily be done - some protocols allow "parallel" calls), the following
   race condition::
@@ -246,7 +249,15 @@ Problems:
     Request A returns /.../ChannelA
     Request B returns /.../ChannelB
- -  can result in unnecessarily opening two parallel calls to the same contact
+  can result in unnecessarily opening two parallel calls to the same contact.
+  (For instance: Empathy users sometimes incorrectly double-click on the
+  Call button, resulting in two calls.)
+  Resolution: UIs are responsible for not doing this. For instance, Empathy
+  should disable (make insensitive) the Call button just before requesting
+  a streamed media channel, and re-enable it when the request has either
+  failed or succeeded.
 Practical implementation::
@@ -967,5 +978,23 @@ Problems:
   cares about and should close/refuse (this use case), and a channel requested
   by another process but handled by it (req5_)
+_`req37`: Requesting a channel takes time
+Romeo makes a VoIP call to Juliet from a Maemo device at a time when he has no
+connectivity. Mission Control (the ChannelDispatcher implementation) on Maemo
+is able to request that the device obtains some sort of connection when
+needed, so it does so. However, Romeo is not near a wireless LAN access
+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
+Proposed implementation: the ChannelDispatcher creates a request "cursor"
+object for the duration of the request
   vim:set sw=4 sts=4 et:



More information about the Telepathy mailing list