[Telepathy-commits] [telepathy-spec/master] Conn.I.Requests: add a straw-man version of EnsureChannel and some musings about whether its design is OK

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


---
 spec/Connection_Interface_Requests.xml |   35 ++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/spec/Connection_Interface_Requests.xml b/spec/Connection_Interface_Requests.xml
index b18d1c5..3c7b7f6 100644
--- a/spec/Connection_Interface_Requests.xml
+++ b/spec/Connection_Interface_Requests.xml
@@ -220,6 +220,41 @@
         </tp:docstring>
       </arg>
 
+      <arg name="Owned_By_Caller" direction="out" type="b">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>False if the caller of EnsureChannel should assume that some other
+            process is handling this channel; true if the caller of
+            EnsureChannel should handle it themselves or delegate it to another
+            client.</p>
+
+          <p>If the creation of a channel makes several calls to EnsureChannel
+            (and no other requests) successful, exactly one of those calls MUST
+            return a true value for this argument.</p>
+
+          <p>If the creation of a channel makes other requests successful,
+            the value returned for this argument MUST be such that exactly
+            one of the clients making requests ends up responsible for the
+            channel. In particular, if CreateChannel returns a channel
+            <em>C</em>, any EnsureChannel calls that also return <em>C</em>
+            MUST return a false value for this argument.</p>
+
+          <tp:rationale>
+            <p>The channel dispatcher must be able to arrange for a channel
+              to be handled exactly once. In the presence of possibly
+              un-cooperative processes, this is quite difficult.</p>
+          </tp:rationale>
+
+          <p>(FIXME: this design is quite complicated, and makes the CM
+            implementation quite subtle. One alternative design would be to
+            have some flag roughly equivalent to the old suppress_handler,
+            which would be true when CreateChannel was called, but false
+            when EnsureChannel was called - not quite the same as Requested,
+            which ought to be true in both cases. Approvers would run iff
+            Requested was false, but handlers would run in response to
+            NewChannels iff the ExclusiveRequest flag was false.)</p>
+        </tp:docstring>
+      </arg>
+
       <arg name="Channel" direction="out" type="o">
         <tp:docstring>
           The Channel object, which MUST already have been signalled with
-- 
1.5.6.5




More information about the Telepathy-commits mailing list