[Telepathy-commits] [telepathy-glib/master] Update spec to 0.17.13
Simon McVittie
simon.mcvittie at collabora.co.uk
Mon Oct 13 10:36:40 PDT 2008
---
spec/Account.xml | 10 ++-
spec/Channel.xml | 123 +++++++++++++++++++++++++++
spec/Channel_Dispatch_Operation.xml | 15 +++-
spec/Channel_Dispatcher.xml | 143 +++++++++++++++++++++++++++++++-
spec/Channel_Future.xml | 123 ---------------------------
spec/Channel_Request.xml | 5 +-
spec/Client.xml | 2 +-
spec/Client_Approver.xml | 6 +-
spec/Client_Handler.xml | 10 +-
spec/Client_Observer.xml | 8 +-
spec/Connection_Interface_Requests.xml | 7 +-
spec/all.xml | 2 +-
12 files changed, 303 insertions(+), 151 deletions(-)
diff --git a/spec/Account.xml b/spec/Account.xml
index 4c32498..5f7b5b7 100644
--- a/spec/Account.xml
+++ b/spec/Account.xml
@@ -346,10 +346,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
</property>
<property name="Connection" tp:name-for-bindings="Connection"
- type="s" access="read">
+ type="o" access="read">
<tp:docstring>
- Either the well-known bus name of the connection to this account,
- or the empty string if there is no connection.
+ Either the object path of the connection to this account,
+ or the special value '/' if there is no connection.
+
+ <tp:rationale>
+ Object paths aren't nullable, so we can't use an empty string.
+ </tp:rationale>
</tp:docstring>
</property>
diff --git a/spec/Channel.xml b/spec/Channel.xml
index 545e84c..f560ed8 100644
--- a/spec/Channel.xml
+++ b/spec/Channel.xml
@@ -274,6 +274,129 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:docstring>
</method>
+ <property name="Requested" tp:name-for-bindings="Requested"
+ type="b" access="read">
+ <tp:added version="0.17.13">(as stable API)</tp:added>
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>True if this channel was created in response to a local request,
+ such as 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.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:name-for-bindings="Initiator_Handle">
+ <tp:added version="0.17.13">(as stable API)</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 value of
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.SelfHandle</tp:dbus-ref>
+ at the time the channel was created (i.e. not a channel-specific
+ handle).</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:name-for-bindings="Initiator_ID">
+ <tp:added version="0.17.13">(as stable API)</tp:added>
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The string that would result from inspecting the
+ <tp:member-ref>InitiatorHandle</tp:member-ref>
+ 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>
+
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>All communication in the Telepathy framework is carried out via channel
objects which are created and managed by connections. This interface must
diff --git a/spec/Channel_Dispatch_Operation.xml b/spec/Channel_Dispatch_Operation.xml
index dfd4ec3..c9f5592 100644
--- a/spec/Channel_Dispatch_Operation.xml
+++ b/spec/Channel_Dispatch_Operation.xml
@@ -38,7 +38,7 @@
<p>More specifically, whenever the
<tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.NewChannels</tp:dbus-ref>
signal contains channels whose
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.FUTURE.Requested</tp:dbus-ref>
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
property is false, or whenever the
<tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.NewChannel</tp:dbus-ref>
signal contains a channel with suppress_handler false,
@@ -140,9 +140,20 @@
<signal name="ChannelLost" tp:name-for-bindings="Channel_Lost">
<tp:docstring>
- A channel has closed before it could be claimed or handled.
+ A channel has closed before it could be claimed or handled. If this
+ is emitted for the last remaining channel in a channel dispatch
+ operation, it MUST immediately be followed by
+ <tp:member-ref>Finished</tp:member-ref>.
</tp:docstring>
+ <arg name="Channel" type="o">
+ <tp:docstring>
+ The <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>
+ that closed.
+ </tp:docstring>
+ </arg>
+
<arg name="Error" type="s" tp:type="DBus_Error_Name">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The name of a D-Bus error indicating why the channel closed. If
diff --git a/spec/Channel_Dispatcher.xml b/spec/Channel_Dispatcher.xml
index 822e7dd..c9b8a2b 100644
--- a/spec/Channel_Dispatcher.xml
+++ b/spec/Channel_Dispatcher.xml
@@ -167,7 +167,9 @@
request is for some reason not involving user action.
The <tp:dbus-ref
namespace="org.freedesktop.Telepathy.ChannelRequest.DRAFT">UserActionTime</tp:dbus-ref>
- property will be set to this value.</p>
+ property will be set to this value, and it will eventually be
+ passed as the <code>User_Action_Time</code> parameter of <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>.</p>
</tp:docstring>
</arg>
@@ -190,7 +192,9 @@
and the Client object on the handler can be located easily.</p>
<p>This is partly so the channel dispatcher can call
- HandleChannel on it, and partly so the channel dispatcher
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
+ on it, and partly so the channel dispatcher
can recover state if it crashes and is restarted.</p>
</tp:rationale>
</tp:docstring>
@@ -217,6 +221,141 @@
</method>
+ <method name="EnsureChannel" tp:name-for-bindings="Ensure_Channel">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Start a request to ensure that a channel exists, creating it if
+ necessary. This initially just creates a <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ object, which can be used to continue the request and track its
+ success or failure.</p>
+
+ <p>If this method is called for an Account that is disabled, invalid
+ or otherwise unusable, no error is signalled until
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT.Proceed</tp:dbus-ref>
+ is called, at which point
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT.Failed</tp:dbus-ref>
+ is emitted with an appropriate error.</p>
+
+ <tp:rationale>
+ <p>The rationale is as for <tp:dbus-ref
+ namespace='org.freedesktop.Telepathy.ChannelDispatcher.DRAFT'>CreateChannel</tp:dbus-ref>.</p>
+ </tp:rationale>
+ </tp:docstring>
+
+ <arg direction="in" name="Account" type="o">
+ <tp:docstring>
+ The
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Account</tp:dbus-ref>
+ for which the new channel is to be created.
+ </tp:docstring>
+ </arg>
+
+ <arg direction="in" name="Requested_Properties" type="a{sv}"
+ tp:type="Qualified_Property_Value_Map">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>A dictionary containing desirable properties. This has the same
+ semantics as the corresponding parameter to
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>.
+ </p>
+
+ <p>Certain properties will not necessarily make sense in this
+ dictionary: for instance,
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
+ can only be given if the requester is able to interact with a
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>
+ to the desired account.</p>
+ </tp:docstring>
+ </arg>
+
+ <arg direction="in" name="User_Action_Time" type="t"
+ tp:type="Unix_Timestamp64">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>The time at which user action occurred, or 0 if this channel
+ request is for some reason not involving user action.
+ The <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.ChannelRequest.DRAFT">UserActionTime</tp:dbus-ref>
+ property will be set to this value, and it will eventually be
+ passed as the <code>User_Action_Time</code> parameter of <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>.</p>
+ </tp:docstring>
+ </arg>
+
+ <arg direction="in" name="Preferred_Handler" type="s"
+ tp:type="DBus_Well_Known_Name">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+ <p>Either the well-known bus name (starting with
+ <code>org.freedesktop.Telepathy.Client.</code>)
+ of the preferred handler for this
+ channel, or an empty string to indicate that any handler would be
+ acceptable.</p>
+
+ <tp:rationale>
+ <p>This must be the well-known bus name, not the unique name,
+ to ensure that all handlers do indeed have the Client API,
+ and the Client object on the handler can be located easily.</p>
+
+ <p>This is partly so the channel dispatcher can call
+ <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandleChannels</tp:dbus-ref>
+ on it, and partly so the channel dispatcher
+ can recover state if it crashes and is restarted.</p>
+ </tp:rationale>
+
+ <p>If any new channels are created in response to this
+ request, the channel dispatcher SHOULD dispatch as many as
+ possible of the resulting channels (ideally, all of them)
+ to that handler, and SHOULD remember the preferred handler
+ so it can try to dispatch subsequent channels in the same bundle
+ to the same handler. If the requested channel already exists (that
+ is, <tp:dbus-ref
+ namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.EnsureChannel</tp:dbus-ref>
+ returns <code>Yours=False</code>) then the channel dispatcher
+ SHOULD re-dispatch the channel to its existing handler, and MUST
+ NOT dispatch it to this client (unless it is the existing handler);
+ the request is still deemed to have succeeded in this case.</p>
+
+ <tp:rationale>
+ <p>An address book application, for example, might call <tp:dbus-ref
+ namespace='org.freedesktop.Telepathy.ChannelDispatcher.DRAFT'>EnsureChannel</tp:dbus-ref>
+ to ensure that a text channel with a particular contact is
+ displayed to the user; it does not care whether a new channel was
+ made. An IM client might call <tp:dbus-ref
+ namespace='org.freedesktop.Telepathy.ChannelDispatcher.DRAFT'>EnsureChannel</tp:dbus-ref>
+ in response to the user double-clicking an entry in the contact
+ list, with itself as the <code>Preferred_Handler</code>; if the
+ user already has a conversation with that contact in another
+ application, they would expect the existing window to be
+ presented, rather than their double-click leading to an error
+ message. So the request should succeed, even if its
+ <code>Preferred_Handler</code> is not used.</p>
+ </tp:rationale>
+
+ </tp:docstring>
+ </arg>
+
+ <arg direction="out" name="Request" type="o">
+ <tp:docstring>
+ A
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest.DRAFT</tp:dbus-ref>
+ object.
+ </tp:docstring>
+ </arg>
+
+ <tp:possible-errors>
+ <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+ <tp:docstring>
+ The Preferred_Handler is syntactically invalid or does
+ not start with <code>org.freedesktop.Telepathy.Client.</code>,
+ the Account does not exist, or one of the Requested_Properties
+ is invalid
+ </tp:docstring>
+ </tp:error>
+ </tp:possible-errors>
+
+ </method>
+
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Future.xml b/spec/Channel_Future.xml
index 131b655..235ff2c 100644
--- a/spec/Channel_Future.xml
+++ b/spec/Channel_Future.xml
@@ -42,129 +42,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
</tp:rationale>
</tp:docstring>
- <property name="Requested" tp:name-for-bindings="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 local request,
- such as 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.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:name-for-bindings="Initiator_Handle">
- <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 value of
- <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.SelfHandle</tp:dbus-ref>
- at the time the channel was created (i.e. not a channel-specific
- handle).</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:name-for-bindings="Initiator_ID">
- <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" tp:name-for-bindings="Bundle"
type="o" access="read">
<tp:added version="0.17.9">(in Channel.FUTURE
diff --git a/spec/Channel_Request.xml b/spec/Channel_Request.xml
index 25f5b06..08b291f 100644
--- a/spec/Channel_Request.xml
+++ b/spec/Channel_Request.xml
@@ -125,10 +125,7 @@
<p>If the connection manager has already returned a channel, but the
channel has not yet been dispatched to a handler
- (e.g. if <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>
- has returned a channel, but the dispatch operation is waiting for
- approvers) then the channel dispatcher will not dispatch that
+ then the channel dispatcher will not dispatch that
channel to a handler. If the channel was newly created for this
request, the channel dispatcher will close it with Close; otherwise,
the channel dispatcher will ignore it. In either case,
diff --git a/spec/Client.xml b/spec/Client.xml
index da3cfbe..d0bb8e5 100644
--- a/spec/Client.xml
+++ b/spec/Client.xml
@@ -22,7 +22,7 @@
<interface name="org.freedesktop.Telepathy.Client.DRAFT"
tp:causes-havoc="experimental">
- <tp:added version="0.17.UNRELEASED"/>
+ <tp:added version="0.17.12">(as a draft)</tp:added>
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Telepathy clients use connection managers, the channel dispatcher
diff --git a/spec/Client_Approver.xml b/spec/Client_Approver.xml
index c912b12..8f59a19 100644
--- a/spec/Client_Approver.xml
+++ b/spec/Client_Approver.xml
@@ -22,7 +22,7 @@
<interface name="org.freedesktop.Telepathy.Client.Approver.DRAFT"
tp:causes-havoc="experimental">
- <tp:added version="0.17.UNRELEASED"/>
+ <tp:added version="0.17.12">(as a draft)</tp:added>
<tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
@@ -87,7 +87,9 @@
tp:name-for-bindings="Add_Dispatch_Operation">
<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>Called by the channel dispatcher when a ChannelDispatchOperation
- in which the approver has registered an interest is created.</p>
+ in which the approver has registered an interest is created,
+ or when the approver starts up while such channel dispatch
+ operations already exist.</p>
<p>The channel dispatcher SHOULD call this method on all approvers
at the same time. If no approvers return from this method
diff --git a/spec/Client_Handler.xml b/spec/Client_Handler.xml
index 4e815d0..84e789f 100644
--- a/spec/Client_Handler.xml
+++ b/spec/Client_Handler.xml
@@ -22,7 +22,7 @@
<interface name="org.freedesktop.Telepathy.Client.Handler.DRAFT"
tp:causes-havoc="experimental">
- <tp:added version="0.17.UNRELEASED"/>
+ <tp:added version="0.17.12">(as a draft)</tp:added>
<tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
@@ -32,8 +32,8 @@
process handling channels of a particular type.</p>
<p>When a new incoming channel (one with
- <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.FUTURE">Requested</tp:dbus-ref>
- = TRUE) is offered to
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
+ = FALSE) is offered to
<tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Approver</tp:dbus-ref>s
by the channel dispatcher, it also offers the Approvers a list of all
the running or activatable ChannelHandlers whose
@@ -43,8 +43,8 @@
those channel handlers to handle the channel.</p>
<p>When a new outgoing channel (one with
- <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.FUTURE">Requested</tp:dbus-ref>
- = FALSE) appears, the channel dispatcher passes it to an appropriate
+ <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
+ = TRUE) appears, the channel dispatcher passes it to an appropriate
channel handler automatically.
</p>
diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml
index eccbefd..89709e2 100644
--- a/spec/Client_Observer.xml
+++ b/spec/Client_Observer.xml
@@ -22,7 +22,7 @@
<interface name="org.freedesktop.Telepathy.Client.Observer.DRAFT"
tp:causes-havoc="experimental">
- <tp:added version="0.17.UNRELEASED"/>
+ <tp:added version="0.17.12">(as a draft)</tp:added>
<tp:requires interface="org.freedesktop.Telepathy.Client.DRAFT"/>
@@ -76,7 +76,7 @@
although of course the ObserverChannelFilter property can be set
to filter on the
<tp:dbus-ref
- namespace="org.freedesktop.Telepathy">Channel.FUTURE.Requested</tp:dbus-ref>
+ namespace="org.freedesktop.Telepathy.Channel">Requested</tp:dbus-ref>
property.</p>
</tp:docstring>
@@ -144,12 +144,12 @@ Interfaces=org.freedesktop.Telepathy.Client.Observer.DRAFT;
[org.freedesktop.Telepathy.Client.Observer.DRAFT.ObserverChannelFilter 0]
org.freedesktop.Telepathy.Channel.Type s=org.freedesktop.Telepathy.Channel.Type.Text
org.freedesktop.Telepathy.Channel.TargetHandleType u=1
-org.freedesktop.Telepathy.Channel.FUTURE.Requested b=true
+org.freedesktop.Telepathy.Channel.Requested b=true
[org.freedesktop.Telepathy.Client.Observer.DRAFT.ObserverChannelFilter 1]
org.freedesktop.Telepathy.Channel.Type s=org.freedesktop.Telepathy.Channel.Type.Text
org.freedesktop.Telepathy.Channel.TargetHandleType u=2
-org.freedesktop.Telepathy.Channel.FUTURE.Requested b=true
+org.freedesktop.Telepathy.Channel.Requested b=true
</pre>
</tp:docstring>
diff --git a/spec/Connection_Interface_Requests.xml b/spec/Connection_Interface_Requests.xml
index c409dca..5576d5b 100644
--- a/spec/Connection_Interface_Requests.xml
+++ b/spec/Connection_Interface_Requests.xml
@@ -80,12 +80,11 @@
<p>Each dictionary MUST contain the keys
<tp:dbus-ref>org.freedesktop.Telepathy.Channel.ChannelType</tp:dbus-ref>,
<tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandleType</tp:dbus-ref>,
- <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandle</tp:dbus-ref>
+ <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandle</tp:dbus-ref>,
+ <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetID</tp:dbus-ref>
and
- <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetID</tp:dbus-ref>.
+ <tp:dbus-ref>org.freedesktop.Telepathy.Channel.Requested</tp:dbus-ref>.
</p>
- <!-- FIXME: maybe also Requested, InitiatorHandle,
- InitiatorID once they leave the FUTURE pseudo-interface -->
<tp:rationale>
<p>We expect these to be crucial to the channel-dispatching
diff --git a/spec/all.xml b/spec/all.xml
index a9c58c1..6f06f72 100644
--- a/spec/all.xml
+++ b/spec/all.xml
@@ -3,7 +3,7 @@
xmlns:xi="http://www.w3.org/2001/XInclude">
<tp:title>Telepathy D-Bus Interface Specification</tp:title>
-<tp:version>0.17.12</tp:version>
+<tp:version>0.17.13</tp:version>
<tp:copyright>Copyright (C) 2005-2008 Collabora Limited</tp:copyright>
<tp:copyright>Copyright (C) 2005-2008 Nokia Corporation</tp:copyright>
--
1.5.6.5
More information about the Telepathy-commits
mailing list