[Telepathy-commits] [telepathy-salut/master] Add Channel.FUTURE interface from 0.17.9

Will Thompson will.thompson at collabora.co.uk
Thu Oct 23 07:30:36 PDT 2008

 extensions/Channel_Future.xml |  184 +++++++++++++++++++++++++++++++++++++++++
 extensions/channel.xml        |    1 +
 2 files changed, 185 insertions(+), 0 deletions(-)
 create mode 100644 extensions/Channel_Future.xml

diff --git a/extensions/Channel_Future.xml b/extensions/Channel_Future.xml
new file mode 100644
index 0000000..ad18879
--- /dev/null
+++ b/extensions/Channel_Future.xml
@@ -0,0 +1,184 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Future"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright (C) 2008 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright (C) 2008 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+modify it under the terms of the GNU Lesser General Public
+License as published by the Free Software Foundation; either
+version 2.1 of the License, or (at your option) any later version.</p>
+<p>This library is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+Lesser General Public License for more details.</p>
+<p>You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Channel.FUTURE"
+    tp:causes-havoc="a staging area for future Channel functionality">
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface contains functionality which we intend to incorporate
+        into the Channel interface in future. It should be considered to
+        be conceptually part of the core Channel interface, but without
+        API or ABI guarantees.</p>
+      <tp:rationale>
+        <p>If we add new functionality to the Channel interface, libraries
+          that use generated code (notably telepathy-glib) will have it as
+          part of their ABI forever, meaning we can't make incompatible
+          changes. By using this interface as a staging area for future
+          Channel functionality, we can try out new properties, signals
+          and methods as application-specific extensions, then merge them
+          into the core Channel interface when we have enough implementation
+          experience to declare them to be stable.</p>
+        <p>The name is by analogy to Python's <code>__future__</code>
+          pseudo-module.</p>
+      </tp:rationale>
+    </tp:docstring>
+    <property name="Requested" type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if this channel was created in response to a call to
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.RequestChannel</tp:dbus-ref>,
+          or
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.DRAFT.CreateChannel</tp:dbus-ref>.</p>
+        <tp:rationale>
+          <p>The idea of this property is to distinguish between "incoming"
+            and "outgoing" channels, in a way that doesn't break down when
+            considering special cases like contact lists that are automatically
+            created on connection to the server, or chatrooms that an
+            IRC proxy/bouncer like irssi-proxy or bip was already in.</p>
+          <p>The reason we want to make that distinction is that UIs for
+            things that the user explicitly requested should start up
+            automatically, whereas for incoming messages and VoIP calls we
+            should first ask the user whether they want to open the messaging
+            UI or accept the call.</p>
+        </tp:rationale>
+        <p>If the channel was not explicitly requested (even if it was
+          created as a side-effect of a call to one of those functions,
+          e.g. because joining a Tube in a MUC context on XMPP implies
+          joining that MUC), then this property is false.</p>
+        <p>For compatibility with older connection managers, clients SHOULD
+          assume that this property is true if they see a channel announced
+          by the
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.NewChannel</tp:dbus-ref>
+          signal with the suppress_handler parameter set to true.</p>
+        <tp:rationale>
+          <p>In a correct connection manager, the only way to get such a
+            channel is to request it.</p>
+        </tp:rationale>
+        <p>Clients MAY additionally assume that this property is false
+          if they see a channel announced by the NewChannel signal with the
+          suppress_handler parameter set to false.</p>
+        <tp:rationale>
+          <p>This is more controversial, since it's possible to get that
+            parameter set to false by requesting a channel. However, there's
+            no good reason to do so, and we've deprecated this practice.</p>
+          <p>In the particular case of the channel dispatcher, the only
+            side-effect of wrongly thinking a channel is unrequested
+            is likely to be that the user has to confirm that they want to
+            use it, so it seems fairly harmless to assume in the channel
+            dispatcher that channels with suppress_handler false are
+            indeed unrequested.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+    <property name="InitiatorHandle" type="u" tp:type="Contact_Handle"
+      access="read">
+      <tp:added version="0.17.7">(in Channel.FUTURE
+        pseudo-interface)</tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The contact who initiated the channel. For channels requested by the
+          local user, this MUST be the same thing as would be returned
+          by Connection.GetSelfHandle() at the time the channel was
+          created.</p>
+        <tp:rationale>
+          <p>The careful wording about the self-handle is because the Renaming
+            interface can cause the return from Connection.GetSelfHandle to
+            change. It's something of a specification bug that we don't signal
+            this in the Connection interface yet.</p>
+        </tp:rationale>
+        <p>For channels requested by a remote user, this MUST be their handle.
+          If unavailable or not applicable, this MUST be 0 (for instance,
+          contact lists are not really initiated by anyone in particular, and
+          it's easy to imagine a protocol where chatroom invitations can be
+          anonymous).</p>
+        <p>For channels with the Group interface, this SHOULD be the same
+          contact who is signalled as the "Actor" causing the self-handle
+          to be placed in the local-pending set.</p>
+        <p>This SHOULD NOT be a channel-specific handle, if possible.</p>
+        <p>It does not make sense for this property to be in channel
+          requests - the initiator will always be the local user - so it
+          MUST NOT be accepted.</p>
+      </tp:docstring>
+    </property>
+    <property name="InitiatorID" type="s" access="read">
+      <tp:added version="0.17.7">(in Channel.FUTURE
+        pseudo-interface)</tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The string that would result from inspecting the InitiatorHandle
+          property (i.e. the initiator's identifier in the IM protocol).</p>
+        <tp:rationale>
+          <p>The presence of this property avoids the following race
+            condition:</p>
+          <ul>
+            <li>New StreamedMedia channel C is signalled with initiator
+              handle I</li>
+            <li>Client calls InspectHandles(CONTACT, [I])</li>
+            <li>Channel C closes, removing the last reference to handle I</li>
+            <li>InspectHandles(CONTACT, [I]) returns an error</li>
+            <li>Client can indicate that a call was missed, but not who
+              called!</li>
+          </ul>
+        </tp:rationale>
+        <p>It does not make sense for this property to be in channel
+          requests - the initiator will always be the local user - so it
+          MUST NOT be accepted.</p>
+      </tp:docstring>
+    </property>
+    <property name="Bundle" type="o" access="read">
+      <tp:added version="0.17.9">(in Channel.FUTURE
+        pseudo-interface)</tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle</tp:dbus-ref>
+          to which this channel belongs.</p>
+        <p>A channel's Bundle property can never change.</p>
+        <p>Older connection managers might not have this property. Clients
+          (particularly the channel dispatcher) SHOULD recover by considering
+          each channel to be in a bundle containing only that channel,
+          distinct from all other bundles, which has no additional
+          interfaces.</p>
+      </tp:docstring>
+    </property>
+  </interface>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/extensions/channel.xml b/extensions/channel.xml
index a82b142..14962f0 100644
--- a/extensions/channel.xml
+++ b/extensions/channel.xml
@@ -23,5 +23,6 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA</p>
 <xi:include href="Channel_Type_File_Transfer.xml"/>
+<xi:include href="Channel_Future.xml"/>

More information about the Telepathy-commits mailing list