[Telepathy-commits] [telepathy-salut/master] extensions/Channel_Future.xml: Remove Requested, InitiatorHandle, InitiatorID because they are integrated in the main Channel interface now (Update from tp-spec)
Alban Crequy
alban.crequy at collabora.co.uk
Wed Oct 22 11:45:43 PDT 2008
---
extensions/Channel_Future.xml | 122 +----------------------------------------
1 files changed, 2 insertions(+), 120 deletions(-)
diff --git a/extensions/Channel_Future.xml b/extensions/Channel_Future.xml
index ad18879..235ff2c 100644
--- a/extensions/Channel_Future.xml
+++ b/extensions/Channel_Future.xml
@@ -42,126 +42,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</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">
+ <property name="Bundle" tp:name-for-bindings="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">
--
1.5.6.5
More information about the Telepathy-commits
mailing list