[Telepathy-commits] [telepathy-spec/master] Add some general notes on new vs existing channels

Simon McVittie simon.mcvittie at collabora.co.uk
Fri Sep 26 08:20:43 PDT 2008


20080609113619-53eee-d6ea33acd8cef44af646283a45f36060f119ebce.gz
---
 doc/request.txt |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/doc/request.txt b/doc/request.txt
index 29e1094..a11caeb 100644
--- a/doc/request.txt
+++ b/doc/request.txt
@@ -1143,5 +1143,36 @@ unless special action is taken
 Proposed implementation: the ChannelDispatcher creates a request "cursor"
 object for the duration of the request
 
+General issues
+--------------
+
+Selecting new or existing channels
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We assume that creating a channel has visible side-effects, and that this
+is undesirable in some cases.
+
+When requesting a single channel, there are four possibilities:
+
+* A: Only a new channel is acceptable
+
+* B: Creating a new channel is preferable, but returning an existing channel
+  would be OK too
+
+* C: Returning an existing channel is preferable, but creating a new channel
+  would be OK too
+
+* D: Only an existing channel is acceptable - creating a new channel is to be
+  avoided
+
+Case A is actually irrelevant - the client can make request B, then fail
+internally if an existing channel was returned (there is no side-effect).
+However, case D must be distinguished from case C, because once the new
+channel has been created, any side-effects have already occurred and it's
+too late to cancel it (e.g. the remote contact will already have been
+notified).
+
+When requesting a bundle of channels, everything gets complicated.
+
 ..
   vim:set sw=4 sts=4 et:
-- 
1.5.6.5




More information about the Telepathy-commits mailing list