[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