Hello community,
here is the log from the commit of package python-telepathy for openSUSE:Factory
checked in at Thu Sep 3 17:09:36 CEST 2009.
--------
--- python-telepathy/python-telepathy.changes 2009-08-12 22:39:32.000000000 +0200
+++ /mounts/work_src_done/STABLE/python-telepathy/python-telepathy.changes 2009-08-25 17:31:04.000000000 +0200
@@ -1,0 +2,14 @@
+Tue Aug 25 17:28:55 CEST 2009 - vuntz@novell.com
+
+- Update to version 0.15.11:
+ + Enhancements:
+ - Add the ChannelTypeFileTransfer interface
+ - Implement the Debug interface (handle logging and stderr
+ output)
+ - Specification 0.17.27.
+ + Fixes:
+ - fdo#23081: Fixing TargetID handle search
+ - Fix GetCapabilities method that was broken and didn't return
+ anything
+
+-------------------------------------------------------------------
calling whatdependson for head-i586
Old:
----
telepathy-python-0.15.10.tar.bz2
New:
----
telepathy-python-0.15.11.tar.bz2
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python-telepathy.spec ++++++
--- /var/tmp/diff_new_pack.nWSRZX/_old 2009-09-03 17:06:47.000000000 +0200
+++ /var/tmp/diff_new_pack.nWSRZX/_new 2009-09-03 17:06:47.000000000 +0200
@@ -1,5 +1,5 @@
#
-# spec file for package python-telepathy (Version 0.15.10)
+# spec file for package python-telepathy (Version 0.15.11)
#
# Copyright (c) 2009 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
@@ -19,8 +19,8 @@
Name: python-telepathy
%define _name telepathy-python
-Version: 0.15.10
-Release: 2
+Version: 0.15.11
+Release: 1
License: LGPL v2.1 or later
Summary: Python library for Telepathy
Url: http://telepathy.freedesktop.org/wiki/Telepathy%20Python
++++++ telepathy-python-0.15.10.tar.bz2 -> telepathy-python-0.15.11.tar.bz2 ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/NEWS new/telepathy-python-0.15.11/NEWS
--- old/telepathy-python-0.15.10/NEWS 2009-07-30 11:43:08.000000000 +0200
+++ new/telepathy-python-0.15.11/NEWS 2009-08-18 17:37:37.000000000 +0200
@@ -1,5 +1,21 @@
+telepathy-python 0.15.11 (2009-08-18)
+=====================================
+
+The "That's not funny" release
+
+Enhancements:
+
+ * Add the ChannelTypeFileTransfer interface
+ * Implement the Debug interface (handle logging and stderr output)
+ * Specification 0.17.27.
+
+Fixes:
+
+ * #23081: Fixing TargetID handle search (Thiago Borges Abdnur)
+ * Fix GetCapabilities method that was broken and didn't return anything
+
telepathy-python 0.15.10 (2009-07-30)
-====================================
+=====================================
The "Come back automake, all is forgiven" release.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/PKG-INFO new/telepathy-python-0.15.11/PKG-INFO
--- old/telepathy-python-0.15.10/PKG-INFO 2009-07-30 11:44:13.000000000 +0200
+++ new/telepathy-python-0.15.11/PKG-INFO 2009-08-18 18:42:20.000000000 +0200
@@ -1,6 +1,6 @@
Metadata-Version: 1.0
Name: telepathy-python
-Version: 0.15.10
+Version: 0.15.11
Summary: UNKNOWN
Home-page: UNKNOWN
Author: UNKNOWN
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Dispatcher.xml new/telepathy-python-0.15.11/spec/Channel_Dispatcher.xml
--- old/telepathy-python-0.15.10/spec/Channel_Dispatcher.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Dispatcher.xml 2009-08-18 17:27:24.000000000 +0200
@@ -74,7 +74,7 @@
All observers are notified simultaneously.</p></dd>
<dt>Approver</dt>p
+ namespace="org.freedesktop.Telepathy.Client">Approver</dt>
<dd>
<p>Approvers notify the user that new channels have been created,
and also select which channel handler will be used for the channel,
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Interface_Call_State.xml new/telepathy-python-0.15.11/spec/Channel_Interface_Call_State.xml
--- old/telepathy-python-0.15.10/spec/Channel_Interface_Call_State.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Interface_Call_State.xml 2009-08-18 17:27:24.000000000 +0200
@@ -25,7 +25,9 @@
progress or call states. The presence of this interface is no guarantee
that call states will actually be signalled (for instance, SIP
implementations are not guaranteed to generate status 180 Ringing, so a
- call can be accepted without the Ringing flag ever having been set).</p>
+ call can be accepted without the Ringing flag ever having been set;
+ similarly, Jingle implementations are not guaranteed to send
+ <code><ringing/></code>).</p>
<p>To notify the other participant in the call that they are on hold,
see
+
+ http://www.w3.org/1999/xhtml">
+ <p>The client can implement streaming for streams whose NATTraversal
+ property is <code>gtalk-p2p</code>.</p>
+
+
+
+
+ http://www.w3.org/1999/xhtml">
+ <p>The client can implement streaming for streams whose NATTraversal
+ property is <code>ice-udp</code>.</p>
+
+
+
+
+ http://www.w3.org/1999/xhtml">
+ <p>The client can implement streaming for streams whose NATTraversal
+ property is <code>wlm-8.5</code>.</p>
+
+
+
+
+ http://www.w3.org/1999/xhtml">
+ <p>The client can implement streaming for streams whose NATTraversal
+ property is <code>wlm-2009</code>.</p>
+
+
+
+
+ tp:docstring
+ <p>The client supports media streaming with H264 (etc.).</p>
+
+ <p>This handler capability token is a one of a family
+ of similar tokens: for any other audio or video codec whose MIME
+ type is audio/<em>subtype</em> or video/<em>subtype</em>, a handler
+ capability token of this form may exist (the subtype MUST appear
+ in lower case in this context). Clients MAY support more
+ codecs than they explicitly advertise support for; clients SHOULD
+ explicitly advertise support for their preferred codec(s), and
+ for codecs like H264 that are, in practice, significant in codec
+ negotiation.</p>
+
+ tp:rationale
+ <p>For instance, the XMPP capability used by the Google Video
+ Chat web client to determine whether a client is compatible
+ with it requires support for H264 video, so an XMPP
+ connection manager that supports this version of Jingle should
+ not advertise the Google Video Chat capability unless there
+ is at least one installed client that declares that it supports
+ <code>video/h264</code> on StreamedMedia channels.</p>
+
+
+ <p>For example, a client could advertise support for
+ Speex, Theora and H264 by having three
+ handler capability tokens,
+ <code>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/speex</code>,
+ <code>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/theora</code> and
+ <code>org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264</code>,
+ in its Capabilities
+ property.</p>
+
+ <p>Clients MAY have media signalling abilities without explicitly
+ supporting any particular codec, and connection managers SHOULD
+ support this usage.</p>
+
+ tp:rationale
+ <p>This is necessary to support gatewaying between two Telepathy
+ connections, in which case the available codecs might not be
+ known to the gatewaying process.</p>
+
+
+
+
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Interface_Tube.xml new/telepathy-python-0.15.11/spec/Channel_Interface_Tube.xml
--- old/telepathy-python-0.15.10/spec/Channel_Interface_Tube.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Interface_Tube.xml 2009-08-18 17:27:24.000000000 +0200
@@ -44,7 +44,7 @@
Channel.Type.StreamTube)
even if no client has indicated via
SetSelfCapabilities
+ namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT2">UpdateCapabilities
that such a tube is supported. They SHOULD also allow clients to offer tubes with any
Service or
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Type_Contact_Search.xml new/telepathy-python-0.15.11/spec/Channel_Type_Contact_Search.xml
--- old/telepathy-python-0.15.10/spec/Channel_Type_Contact_Search.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Type_Contact_Search.xml 2009-08-18 17:27:24.000000000 +0200
@@ -18,9 +18,10 @@
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>
-
+ (draft 2)
http://www.w3.org/1999/xhtml">
<p>A channel type for searching server-stored user directories. A new
@@ -375,13 +376,15 @@
</method>
-
- <arg name="Contact" type="u" tp:type="Contact_Handle">
- tp:docstringAn integer handle for the contact, which will remain
- valid at least until this Channel closes
- </arg>
- <arg name="Info" type="a(sasas)" tp:type="Contact_Info_Field[]">
+
+ tp:docstringA map from contact handle to search result.
+
+ tp:docstring
+ An integer handle for the contact.
+
+
+
+
http://www.w3.org/1999/xhtml">
<p>An array of fields representing information about this
contact, in the same format used in the
+
+
+
+
+ <arg name="Result" type="a{ua(sasas)}" tp:type="Contact_Search_Result_Map">
+ tp:docstringA mapping from contact handle to an array of fields
+ representing information about this contact. Handles in this mapping
+ MUST remain valid until the Channel closes.
</arg>
tp:docstring
- Emitted when a search result is received from the server.
+ Emitted when a some search results are received from the server.
+ This signal can be fired arbitrarily many times so clients MUST NOT
+ assume they'll get only one signal.
</signal>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Type_File_Transfer.xml new/telepathy-python-0.15.11/spec/Channel_Type_File_Transfer.xml
--- old/telepathy-python-0.15.10/spec/Channel_Type_File_Transfer.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Type_File_Transfer.xml 2009-08-18 17:27:24.000000000 +0200
@@ -80,7 +80,7 @@
<p>Connection managers SHOULD NOT advertise support for file transfer to
other contacts unless it has been indicated by a call to
SetSelfCapabilities.
+ namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT2">UpdateCapabilities.
</p>
tp:rationale
<p>People would send us files, and it would always fail. That would be silly.</p>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Type_Streamed_Media.xml new/telepathy-python-0.15.11/spec/Channel_Type_Streamed_Media.xml
--- old/telepathy-python-0.15.10/spec/Channel_Type_Streamed_Media.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Type_Streamed_Media.xml 2009-08-18 17:27:24.000000000 +0200
@@ -549,6 +549,31 @@
NATs.
+
+
+ tp:docstring
+ Once streams have been requested for a channel to this handle (either
+ by calling tp:member-refRequestStreams on a channel
+ with no streams, or by specifying InitialAudio
+ or InitialAudio
+ = <tt>True</tt> in the channel request), then they cannot be changed;
+ subsequent calls to tp:member-refRequestStreams or
+ tp:member-refRemoveStreams will fail.
+
+ tp:rationale
+ For example, once an audio-only Google Talk call has started, it is
+ not possible to add a video stream; both audio and video must be
+ requested at the start of the call if video is desired. User
+ interfaces may use this pseudo-capability as a hint to display
+ separate "Audio call" and "Video call" buttons, rather than a
+ single "Call" button with the option to add and remove video once
+ the call has started for contacts without this flag.
+
+
+
+
</interface>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Channel_Type_Streamed_Media_Future.xml new/telepathy-python-0.15.11/spec/Channel_Type_Streamed_Media_Future.xml
--- old/telepathy-python-0.15.10/spec/Channel_Type_Streamed_Media_Future.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Channel_Type_Streamed_Media_Future.xml 2009-08-18 17:27:24.000000000 +0200
@@ -90,7 +90,7 @@
<p>Connection managers that support the ContactCapabilities.DRAFT
+ namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities.DRAFT2
interface SHOULD represent the capabilities of receiving audio
and/or video calls by including a channel class in
a contact's capabilities with ChannelType = StreamedMedia
@@ -106,8 +106,9 @@
<p>Clients that are willing to receive audio and/or video calls
- SHOULD include the following filters if calling SetSelfCapabilities
+ SHOULD include the following among their channel classes if
+ calling UpdateCapabilities
(clients of a ChannelDispatcher
SHOULD instead arrange for the ChannelDispatcher to do this,
@@ -147,5 +148,63 @@
</property>
+
+ http://www.w3.org/1999/xhtml">
+ <p>If <tt>True</tt>, once streams have been requested for this channel
+ (either by setting tp:member-refInitialAudio or
+ tp:member-refInitialVideo when the channel is
+ requested, or by calling RequestStreams
+ on a channel with no streams), the channel's streams cannot be changed;
+ subsequent calls to RequestStreams
+ or RemoveStreams
+ will fail.</p>
+
+ <p>If this property is missing, clients SHOULD assume that it is false,
+ and thus that the channel's streams can be changed once the call has
+ started.</p>
+
+ <p>If this property is present in all of the StreamedMedia
+ entries in a contact's capabilities, then user interfaces MAY choose
+ to show a separate "call" option for each class of call.</p>
+
+ tp:rationale
+ <p>On protocols like XMPP Jingle, it is possible to start an
+ audio-only call and then add a video stream, so the user interface
+ could be a single "call" button, which places an audio call, and an
+ "enable video" button in the call interface. However, on protocols
+ like Google Talk it is not possible to upgrade a call once it has
+ started; the user interface will thus need to adapt in order to
+ allow the user to place video calls.</p>
+
+
+ <p>For incoming channels, this property MUST be included in the channel's immutable properties
+ (as announced in NewChannels,
+ etc.). For outgoing calls, this property MAY be omitted from the
+ channel's immutable properties for calls without
+ tp:member-refInitialAudio or
+ tp:member-refInitialVideo, in which case its value
+ is undefined until RequestStreams
+ has been called at least once.</p>
+
+ tp:rationale
+ <p>The protocol mechanism used for the call might only be selected
+ when the CM knows what kind of call is desired. For example, if an
+ XMPP contact is signed in with Google Mail (with video support) and
+ Another client which supports modern Jingle (which supports
+ modifying the streams in a call) but only for audio calls, the
+ call's streams will be immutable if the UI requests Audio+Video,
+ but mutable if the UI just requests audio (a second audio stream
+ could be added, for instance).</p>
+
+
+ </property>
+
</interface>
</node>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Client_Approver.xml new/telepathy-python-0.15.11/spec/Client_Approver.xml
--- old/telepathy-python-0.15.10/spec/Client_Approver.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Client_Approver.xml 2009-08-18 17:27:24.000000000 +0200
@@ -177,10 +177,11 @@
<arg name="Properties" type="a{sv}"
tp:type="Qualified_Property_Value_Map" direction="in">
tp:docstring
- <p>Properties of the channel dispatch operation. This MUST NOT
- include properties that could change, SHOULD include as many
- properties as possible given that constraint, and MUST include at
- least the Account,
Connection
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Client_Handler.xml new/telepathy-python-0.15.11/spec/Client_Handler.xml
--- old/telepathy-python-0.15.10/spec/Client_Handler.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Client_Handler.xml 2009-08-18 17:27:24.000000000 +0200
@@ -109,6 +109,71 @@
</property>
+
+ tp:docstring
+ A tp:typeDBus_Interface, followed by a slash '/' character
+ and an identifier for a capability defined by that interface. The
+ capability identifier SHOULD be in lower case. If an interface
+ references an external specification which is case-insensitive (such
+ as MIME), then names from that specification MUST be normalized to
+ lower-case before providing them to this Telepathy API, so that
+ implementations can safely rely on simple byte-by-byte comparison.
+
+ tp:rationale
+ These aren't D-Bus core Properties, and we want them to look visibly
+ different.
+
+
+ <p>So far, all client capabilities are defined by the MediaSignalling
+ interface.</p>
+
+
+
+
+ http://www.w3.org/1999/xhtml">
+ <p>The set of additional capabilities supported by this handler.
+ This describes things like support for streamed media codecs and
+ NAT traversal mechanisms: see the Contact Capabilities
+ interface for more details.</p>
+
+ <p>For handlers that have a <code>.client</code> file, the
+ channel dispatcher may discover this property from the
+ <code>org.freedesktop.Telepathy.Client.Handler.Capabilities</code>
+ group; for each capability, that group contains a key
+ whose name is the capability, with value <code>true</code>.
+ Keys with other values SHOULD NOT appear in this group.</p>
+
+ <p>For instance, the <code>.client</code> file for a streamed media
+ handler that supports ICE-UDP NAT traversal, Speex audio,
+ and Theora and H264 video might contain this group:</p>
+
+<pre>
+[org.freedesktop.Telepathy.Client.Handler.Capabilities]
+org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp=true
+org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/speex=true
+org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/theora=true
+org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
+</pre>
+
+ <p>Like the tp:member-refHandlerChannelFilter
+ property, this property cannot change while the Handler owns its
+ Client bus name. However, the <code>.client</code> file, if any,
+ can change (due to upgrades or installation of pluggable codecs),
+ and the capabilities really supported by the handler might not
+ exactly match what is cached in the <code>.client</code> file.</p>
+
+ tp:rationale
+ <p>The client file is installed statically and is intended to list
+ codecs etc. that the handler guarantees it can support (e.g. by
+ having a hard dependency on them), whereas the running handler
+ process might be able to find additional codecs.</p>
+
+
+ </property>
+
<method name="HandleChannels" tp:name-for-bindings="Handle_Channels">
http://www.w3.org/1999/xhtml">
<p>Called by the channel dispatcher when this client should handle these
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection.xml new/telepathy-python-0.15.11/spec/Connection.xml
--- old/telepathy-python-0.15.10/spec/Connection.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection.xml 2009-08-18 17:27:24.000000000 +0200
@@ -698,8 +698,18 @@
http://www.w3.org/1999/xhtml">
<p>There was an error sending or receiving on the network socket.</p>
- <p>When disconnected for this reason, the equivalent D-Bus error is
- <code>org.freedesktop.Telepathy.Error.NetworkError</code>.</p>
+ <p>When the status changes from Connecting to Disconnected for this
+ reason, the equivalent D-Bus error is either
+ <code>org.freedesktop.Telepathy.Error.NetworkError</code>,
+ <code>org.freedesktop.Telepathy.Error.ConnectionRefused</code>,
+ <code>org.freedesktop.Telepathy.Error.ConnectionFailed</code>
+ or some more specific error.</p>
+
+ <p>When the status changes from Connected to Disconnected for this
+ reason, the equivalent D-Bus error is either
+ <code>org.freedesktop.Telepathy.Error.NetworkError</code>,
+ <code>org.freedesktop.Telepathy.Error.ConnectionLost</code>
+ or some more specific error.</p>
@@ -737,12 +747,17 @@
<li>If the status change is from Connecting to Disconnected
and the 'register' parameter to RequestConnection was present
and true, the requested account could not be created on the
- server because it already exists.</li>
+ server because it already exists.
+ The equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.RegistrationExists</code>.
+ </li>
<li>If the status change is from Connecting to Disconnected
but the 'register' parameter is absent or false, the connection
manager could not connect to the specified account because
a connection to that account already exists.
+ The equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.AlreadyConnected</code>.
tp:rationale
In some protocols, like XMPP (when connecting with the same
@@ -755,6 +770,8 @@
the existing connection was automatically disconnected because
a new connection to the same account (perhaps from a different
client or location) was established.
+ The equivalent D-Bus error is
+ <code>org.freedesktop.Telepathy.Error.ConnectionReplaced</code>.
tp:rationale
In some protocols, like MSNP (when connecting twice with the
@@ -763,15 +780,6 @@
</li>
</ul>
-
- <p>When disconnected for this reason, the equivalent D-Bus error is
- <code>org.freedesktop.Telepathy.Error.NotYours</code>.
- </p>
-
- tp:rationale
- These three errors are distinct but very similar, and can be
- distinguished by other factors.
-
@@ -897,8 +905,12 @@
tp:docstring
The name of a D-Bus error describing the error that occurred,
which may correspond to a
- tp:typeConnection_Status_Reason or be a
- protocol-specific or connection-manager-specific error in a
+ tp:typeConnection_Status_Reason, or may be a more
+ specific Telepathy error
+ (such as
+ <code>org.freedesktop.Telepathy.Errors.ConnectionRefused</code>
+ for Connection_Status_Reason_Network_Error)
+ or a protocol-specific or connection-manager-specific error in a
suitable namespace.
tp:rationale
@@ -954,6 +966,16 @@
</signal>
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same string that would be returned by
+ tp:member-refInspectHandles. As a special case,
+ this is always present in the result of GetContactAttributes,
+ whether it was explicitly requested or not.</p>
+
+
+
http://www.w3.org/1999/xhtml">
<p>This models a connection to a single user account on a communication
service. Its basic capability is to provide the facility to request and
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Aliasing.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Aliasing.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Aliasing.xml 2009-06-11 18:44:51.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Aliasing.xml 2009-08-18 17:27:24.000000000 +0200
@@ -152,6 +152,18 @@
</method>
+
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same string that would be returned by
+ tp:member-refGetAliases
+ (always present with some value, possibly the
+ same as Connection/contact-id, if information from the
+ Aliasing interface was requested)
+ </p>
+
+
+
http://www.w3.org/1999/xhtml">
<p>An interface on connections to support protocols where contacts have an
alias which they can change at will. Provides a method for the user to set
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Avatars.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Avatars.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Avatars.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Avatars.xml 2009-08-18 17:27:24.000000000 +0200
@@ -450,6 +450,21 @@
</method>
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same string that would be returned by
+ tp:member-refGetKnownAvatarTokens
+ (omitted from the result if the contact's avatar token is not known,
+ present as an empty string if the contact is known not to have
+ an avatar). Unlike in the
+ tp:member-refGetKnownAvatarTokens
+ method, the avatar tokens for the self handle aren't required to be
+ present. This attribute should not be used to determine whether or
+ not the Avatar needs to be set.
+ </p>
+
+
+
http://www.w3.org/1999/xhtml">
<p>An interface for requesting avatars for contacts on a given connection,
receiving notification when avatars are changed, and publishing your own
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Capabilities.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Capabilities.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Capabilities.xml 2009-06-11 18:44:51.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Capabilities.xml 2009-08-18 17:27:24.000000000 +0200
@@ -56,12 +56,6 @@
well-defined or consistent, and as far as we know it was never
implemented correctly. This usage is now deprecated.
- <!-- FIXME: are the type-specific flags sufficient, in a world that has
- the Requests interface? It'd be nice if we could advertise capabilities
- that are not defined in terms of a channel type but rather in terms of
- a property or something, e.g. Channel.Interface.TLS.Secure for
- individually TLS'd channels. -->
-
@@ -160,6 +154,11 @@
that the set is kept accurate - for example, a client may remove
capabilities or type specific capability flags when it exits
which are still provided by another client.</p>
+
+ <p>On connections managed by the ChannelDispatcher,
+ this method SHOULD NOT be used by clients other than the
+ ChannelDispatcher itself.</p>
tp:possible-errors
@@ -231,6 +230,18 @@
</method>
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same structs that would be returned by
+ tp:member-refGetCapabilities
+ (all of them will redundantly have the contact's handle as the
+ first member). Omitted from the result if the contact's capabilities
+ are not known; present in the result as an empty array if the
+ contact is known to have no capabilities at all.</p>
+
+
+
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Contact_Capabilities.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Contact_Capabilities.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Contact_Capabilities.xml 2009-06-11 18:44:51.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Contact_Capabilities.xml 2009-08-18 17:27:24.000000000 +0200
@@ -18,10 +18,11 @@
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>
-
(as a draft)
+ (draft 2)
http://www.w3.org/1999/xhtml">
<p>Contact capabilities describe the channel classes which may be
@@ -38,38 +39,77 @@
<p>This interface also enables user interfaces to notify the connection
manager what capabilities to advertise for the user to other contacts.
This is done by using the
- tp:member-refSetSelfCapabilities method, and deals
- with channel property values pertaining to them which are implemented
- by available client processes.</p>
+ tp:member-refUpdateCapabilities method.</p>
+ tp:rationale
+ <p>XMPP is a major user of this interface: XMPP contacts will not,
+ in general, be callable using VoIP unless they advertise suitable
+ Jingle capabilities.</p>
+
+ <p>Many other protocols also have some concept of capability flags,
+ which this interface exposes in a protocol-independent way.</p>
+
-
-
+ tp:docstring
+ A structure representing the capabilities of a single client.
+
+
+
+ tp:docstring
+ For implementations of the Client
+ interface, the well-known bus name name of the client; for any other
+ process, any other reversed domain name that uniquely identifies it.
+
+
+
+
http://www.w3.org/1999/xhtml">
- An array of channel classes to replace to the list of what the
- connection can handle. If you include optional properties, they
- may not get advertised. The given properties are matched to the
- mandatory properties.
+ An array of channel classes that can be handled by this client.
+ This will usually be a copy of the client's HandlerChannelFilter
+ property.
- </arg>
+
+
+
+ http://www.w3.org/1999/xhtml">
+ An array of client capabilities supported by this client, to be
+ used by the connection manager to determine what capabilities to
+ advertise. This will usually be a copy of the client's Capabilities
+ property.
+
+
+
+
+ <method name="UpdateCapabilities" tp:name-for-bindings="Update_Capabilities">
http://www.w3.org/1999/xhtml">
- <p>Used by user interfaces to indicate which channel classes they are
- able to handle on this connection. It replaces the previous advertised
- channel classes by the set given as parameter.</p>
-
- <p>If a channel class is unknown by the connection manager, it is just
- ignored. No error are returned in this case, and other known channel
- class are added.</p>
-
- <p>Upon a successful invocation of this method, the
- tp:member-refContactCapabilitiesChanged signal
- will only be emitted for the user's own
- handle (as returned by GetSelfHandle) by the connection manager if, in
- the given protocol, the given capabilities are distinct from the
- previous state.</p>
+ <p>Alter the connection's advertised capabilities to include
+ the intersection of the given clients' capabilities with what the
+ connection manager is able to implement.</p>
+
+ <p>On connections managed by the ChannelDispatcher, processes other
+ than the ChannelDispatcher SHOULD NOT call this method, and the
+ ChannelDispatcher SHOULD use this method to advertise the
+ capabilities of all the registered Client.Handler
+ implementations.On connections not managed by the ChannelDispatcher,
+ clients MAY use this method directly, to indicate the channels they
+ will handle and the extra capabilities they have.</p>
+
+ <p>Upon a successful invocation of this method, the connection manager
+ will only emit the
+ tp:member-refContactCapabilitiesChanged signal
+ for the user's SelfHandle
+ if, in the underlying protocol, the new capabilities are distinct
+ from the previous state.</p>
tp:rationale
<p>The connection manager will essentially intersect the provided
@@ -79,10 +119,45 @@
channel) will almost certainly not be advertised.</p>
+ <p>This method MAY be called on a newly-created connection while it
+ is still in the DISCONNECTED state, to request that when the
+ connection connects, it will do so with the appropriate
+ capabilities. Doing so MUST NOT fail.</p>
+
+
+ tp:docstring
+ <p>The capabilities of one or more clients.</p>
+
+ <p>For each client in the given list, any capabilities previously
+ advertised for the same client name are discarded, then replaced by
+ the capabilities indicated.</p>
+
+ <p>As a result, if a client becomes unavailable, this method SHOULD
+ be called with a tp:typeHandler_Capabilities structure
+ containing its name, an empty list of channel classes, and an
+ empty list of capabilities. When this is done, the connection
+ manager SHOULD free all memory associated with that client name.</p>
+
+ tp:rationale
+ <p>This method takes a list of clients so that
+ when the channel dispatcher first calls it (with a list of all
+ the Handlers that are initially available), the changes can be
+ made atomically, with only one transmission of updated
+ capabilities to the network. Afterwards, the channel dispatcher
+ will call this method with a single-element list every time
+ a Handler becomes available or unavailable.</p>
+
+
+ <p>The connection manager MUST ignore any channel classes and client
+ capabilities for which there is no representation in the protocol
+ or no support in the connection manager.</p>
+
+ </arg>
+
tp:possible-errors
-
</method>
@@ -95,11 +170,6 @@
<p>The handle zero MUST NOT be included in the request.</p>
</arg>
- <!-- There was a bug in dbus-glib that prevent to use the right type:
- Instead of a{ua(a{sv}as)}, we used a(ua{sv}as) as a workaround.
- See http://bugs.freedesktop.org/show_bug.cgi?id=17329
- Now there is a fix, so we don't use the workaround anymore.
- -->
<arg direction="out" type="a{ua(a{sv}as)}"
tp:type="Contact_Capabilities_Map" name="Contact_Capabilities">
http://www.w3.org/1999/xhtml">
@@ -161,6 +231,17 @@
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same structs that would be returned by
+ tp:member-refGetContactCapabilities.
+ Omitted from the result if the contact's capabilities
+ are not known; present in the result as an empty array if the
+ contact is known to have no capabilities at all.</p>
+
+
+
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Contacts.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Contacts.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Contacts.xml 2009-06-11 18:44:51.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Contacts.xml 2009-08-18 17:27:24.000000000 +0200
@@ -29,70 +29,6 @@
<p>Each contact attribute has an string identifier
(tp:typeContact_Attribute), which is namespaced
by the D-Bus interface which defines it.</p>
-
- <p>An initial set of contact attributes is defined here:</p>
-
- <dl>
- <dt>org.freedesktop.Telepathy.Connection/contact-id
- (type s)</dt>
- <dd>The same string that would be returned by
- InspectHandles
- (always present in the result)
- </dd>
- <dt>org.freedesktop.Telepathy.Connection.Interface.Aliasing/alias
- (type s)</dt>
- <dd>The same string that would be returned by GetAliases
- (always present with some value, possibly the
- same as Connection/contact-id, if information from the
- Aliasing interface was requested)
- </dd>
- <dt>org.freedesktop.Telepathy.Connection.Interface.Avatars/token
- (type s, tp:typeAvatar_Token)</dt>
- <dd>The same string that would be returned by GetKnownAvatarTokens
- (omitted from the result if the contact's avatar token is not known,
- present as an empty string if the contact is known not to have
- an avatar). Unlike in the GetKnownAvatarTokens
- method, the avatar tokens for the self handle aren't required to be
- present. This attribute should not be used to determine whether or
- not the Avatar needs to be set.
- </dd>
- <dt>org.freedesktop.Telepathy.Connection.Interface.SimplePresence/presence
- (type (uss), tp:typeSimple_Presence)</dt>
- <dd> The same struct that would be returned by
- GetPresences
- (always present with some value if information from the
- SimplePresence interface was requested)
- </dd>
- <dt>org.freedesktop.Telepathy.Connection.Interface.Capabilities/caps
- (type a(usuu), tp:typeContact_Capability)</dt>
- <dd>The same structs that would be returned by
- GetCapabilities
- (all of them will redundantly have the contact's handle as the
- first member). Omitted from the result if the contact's capabilities
- are not known; present in the result as an empty array if the
- contact is known to have no capabilities at all.</dd>
-
- <dt>org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT/caps
- (type a{ua(a{sv}as)},
- tp:typeContact_Capabilities_Map)</dt>
- <dd>The same structs that would be returned by
- GetContactCapabilities
- Omitted from the result if the contact's capabilities
- are not known; present in the result as an empty array if the
- contact is known to have no capabilities at all.</dd>
-
- <dt>org.freedesktop.Telepathy.Connection.Interface.Location.DRAFT/location
- (type a{sv}, tp:typeLocation)</dt>
- <dd>The same struct used by
- GetLocations
- Omitted from the result if the contact's location
- is not known.</dd>
-
- </dl>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Location.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Location.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Location.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Location.xml 2009-08-18 17:27:24.000000000 +0200
@@ -18,9 +18,8 @@
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>
-
- (as a draft)
+ <interface name="org.freedesktop.Telepathy.Connection.Interface.Location">
+ (as stable API)
http://www.w3.org/1999/xhtml">
@@ -50,6 +49,8 @@
possible.</p>
+ <!-- Potentially to be reinstated later:
+ http://bugs.freedesktop.org/show_bug.cgi?id=19585
<tp:enum name="Location_Accuracy_Level" type="i">
<tp:docstring>
A location accuracy level. This should be kept in sync with
@@ -89,11 +90,11 @@
</tp:enumvalue>
<tp:enumvalue suffix="Detailed" value="6">
<tp:docstring>
- The location's accuracy is given by the error, horizontal-error-m
- and/or vertical-error-m keys.
+ The location's accuracy is given by the accuracy key.
</tp:docstring>
</tp:enumvalue>
</tp:enum>
+ -->
tp:docstring
@@ -137,6 +138,15 @@
information about it</li>
</ul>
+ <p>Since the previous strings have data intended to be read by users,
+ the language used should be stated using:</p>
+
+ <ul>
+ <li>language - s: a specific language or locale of location
+ information in a format compatible to RFC 4646. Note that UTF-8
+ is the only allowed encoding, e.g. "en" or "fr-CA".</li>
+ </ul>
+
<p>Positions are represented by the following well-known keys:</p>
<ul>
@@ -164,6 +174,9 @@
This is from XEP-0080
</li>
+
+ <!-- Potentially to be reinstated later:
+ http://bugs.freedesktop.org/show_bug.cgi?id=19585
<li>accuracy-level - i (<tp:type>Location_Accuracy_Level</tp:type>):
an indication of accuracy, which SHOULD be omitted if it would be
Location_Accuracy_Level_None or
@@ -174,24 +187,12 @@
with any future XEP-0080 terminology.
</tp:rationale>
</li>
- <li>error - d: horizontal position error in arc-minutes (1/60
- degree) if known
- <tp:rationale>
- This is from XEP-0080
- </tp:rationale>
- </li>
- <li>vertical-error-m - d: vertical position error in metres if
- known
- <tp:rationale>
- This exists as a struct field in GeoClue; the name is new
- in this specification.
- </tp:rationale>
- </li>
- <li>horizontal-error-m - d: horizontal position error in metres if
+ -->
+
+ <li>accuracy - d: horizontal position error in metres if
known
tp:rationale
- This exists as a struct field in GeoClue; the name is new
- in this specification.
+ This is from XEP-0080
</li>
</ul>
@@ -211,12 +212,6 @@
called "direction" in GeoClue
</li>
- <li>climb - d: rate of change of 'alt' in metres per second
- tp:rationale
- This is a struct field in GeoClue; the name is new to this
- specification, but seems uncontroversial
-
- </li>
</ul>
<p>Other well-known keys:</p>
@@ -389,6 +384,17 @@
set it to be as restrictive as possible (an empty whitelist, if
supported).
</property>
+
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same mapping that would be returned by
+ tp:member-refGetLocations for this contact.
+ Omitted from the result if the contact's location
+ is not known.</p>
+
+
+
</interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Interface_Simple_Presence.xml new/telepathy-python-0.15.11/spec/Connection_Interface_Simple_Presence.xml
--- old/telepathy-python-0.15.10/spec/Connection_Interface_Simple_Presence.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Interface_Simple_Presence.xml 2009-08-18 17:27:24.000000000 +0200
@@ -395,7 +395,7 @@
This type isn't actually used by the SimplePresence interface, but
it's included here so it can be referenced by rich presence interfaces
such as Location.DRAFT.
+ namespace="org.freedesktop.Telepathy.Connection.Interface">Location.
@@ -412,6 +412,16 @@
+
+ http://www.w3.org/1999/xhtml">
+ <p>The same struct that would be returned by
+ tp:member-refGetPresences
+ (always present with some value if information from the
+ SimplePresence interface was requested)</p>
+
+
+
http://www.w3.org/1999/xhtml">
<p>This interface is for services which have a concept of presence which
can be published for yourself and monitored on your contacts.</p>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Connection_Manager.xml new/telepathy-python-0.15.11/spec/Connection_Manager.xml
--- old/telepathy-python-0.15.10/spec/Connection_Manager.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Connection_Manager.xml 2009-08-18 17:27:24.000000000 +0200
@@ -303,6 +303,11 @@
<dt>stun-port (q)</dt>
<dd>The UDP port number on the stun-server to use for STUN. Only
significant if the stun-server is also supplied.</dd>
+
+ <dt>keepalive-interval (u)</dt>
+ <dd>The time in seconds between pings sent to the server to ensure
+ that the connection is still alive, or <tt>0</tt> to disable such
+ pings.</dd>
</dl>
<p>Every successful RequestConnection call will cause the emission of a
@@ -444,7 +449,7 @@
<dt>b (boolean)</dt>
<dd>"true" (case-insensitively) or "1" means True, "false"
(case-insensitively) or "0" means False</dd>
- <dt>q, u, t (16-, 32-, 64-bit unsigned integer)</dt>
+ <dt>y, q, u, t (8-, 16-, 32-, 64-bit unsigned integer)</dt>
<dd>ASCII decimal integer</dd>
<dt>n, i, x (16-, 32-, 64-bit signed integer)</dt>
<dd>ASCII decimal integer, optionally prefixed with "-"</dd>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Debug.xml new/telepathy-python-0.15.11/spec/Debug.xml
--- old/telepathy-python-0.15.10/spec/Debug.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Debug.xml 2009-08-18 17:27:24.000000000 +0200
@@ -17,9 +17,8 @@
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>
-
-
+ <interface name="org.freedesktop.Telepathy.Debug">
+ (as stable API)
http://www.w3.org/1999/xhtml">
<p>An interface for providing debug messages.</p>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/Media_Stream_Handler.xml new/telepathy-python-0.15.11/spec/Media_Stream_Handler.xml
--- old/telepathy-python-0.15.10/spec/Media_Stream_Handler.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/Media_Stream_Handler.xml 2009-08-18 17:27:24.000000000 +0200
@@ -265,12 +265,59 @@
tp:docstring
- An unknown error occured.
+ An unknown error occured.
tp:docstring
- The end of the stream was reached.
+ The end of the stream was reached.
+
+
+ This error has no use anywhere. In Farsight 1 times, it was used to
+ indicate a GStreamer EOS (when the end of a file is reached). But
+ since this is for live calls, it makes no sense.
+
+
+
+
+ tp:docstring
+ There are no common codecs between the local side
+ and the other particpants in the call. The possible codecs are not
+ signalled here: the streaming implementation is assumed to report
+ them in an implementation-dependent way, e.g. Farsight should use
+ GstMissingElement.
+
+
+
+
+ tp:docstring
+ A network connection for the Media could not be established or was
+ lost.
+
+
+
+
+ tp:docstring
+ There was an error in the networking stack
+ (other than the connection failure).
+
+
+
+
+ tp:docstring
+ There are no installed codecs for this media type.
+
+
+
+
+ tp:docstring
+ The CM is doing something wrong.
+
+
+
+
+ tp:docstring
+ There was an error in the media processing stack.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/all.xml new/telepathy-python-0.15.11/spec/all.xml
--- old/telepathy-python-0.15.10/spec/all.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/all.xml 2009-08-18 17:27:24.000000000 +0200
@@ -3,7 +3,7 @@
xmlns:xi="http://www.w3.org/2001/XInclude">
tp:titleTelepathy D-Bus Interface Specification
-tp:version0.17.26
+tp:version0.17.27
tp:copyrightCopyright © 2005-2009 Collabora Limited
tp:copyrightCopyright © 2005-2009 Nokia Corporation
@@ -106,7 +106,6 @@
-
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/spec/errors.xml new/telepathy-python-0.15.11/spec/errors.xml
--- old/telepathy-python-0.15.10/spec/errors.xml 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/spec/errors.xml 2009-08-18 17:27:24.000000000 +0200
@@ -71,9 +71,13 @@
- tp:docstring
- The requested channel or other resource already exists, and another
- client is responsible for it
+ http://www.w3.org/1999/xhtml">
+ <p>The requested channel or other resource already exists, and another
+ user interface in this session is responsible for it.</p>
+
+ <p>User interfaces SHOULD handle this error unobtrusively, since it
+ indicates that some other user interface is already processing the
+ channel.</p>
@@ -260,7 +264,9 @@
tp:docstring
Used to represent a user being removed from a channel because of a
- "busy" indication.
+ "busy" indication. This error SHOULD NOT be used to represent a server
+ or other infrastructure being too busy to process a request - for that,
+ see ServerBusy.
tp:rationale
This corresponds to Busy in the
@@ -325,6 +331,72 @@
+
+ tp:docstring
+ Raised when the user attempts to connect to an account but they are
+ already connected (perhaps from another client or computer), and the
+ protocol or account settings do not allow this.
+
+ tp:rationale
+ XMPP can have this behaviour if the user chooses the same resource
+ in both clients (it is server-dependent whether the result is
+ AlreadyConnected on the new connection, ConnectionReplaced on the
+ old connection, or two successful connections).
+
+
+
+
+
+ tp:docstring
+ Raised by an existing connection to an account if it is replaced by
+ a new connection (perhaps from another client or computer).
+
+ tp:rationale
+ In MSNP, when connecting twice with the same Passport, the new
+ connection "wins" and the old one is automatically disconnected.
+ XMPP can also have this behaviour if the user chooses the same
+ resource in two clients (it is server-dependent whether the result is
+ AlreadyConnected on the new connection, ConnectionReplaced on the
+ old connection, or two successful connections).
+
+
+
+
+
+ tp:docstring
+ Raised during in-band registration if the server indicates that the
+ requested account already exists.
+
+
+
+
+ http://www.w3.org/1999/xhtml">
+ Raised if a server or some other piece of infrastructure cannot process
+ the request, e.g. due to resource limitations. Clients MAY try again
+ later.
+
+ tp:rationale
+ This is not the same error as Busy, which indicates that a
+ <em>user</em> is busy.
+
+
+
+
+
+ tp:docstring
+ Raised if a request cannot be satisfied because a process local to the
+ user has insufficient resources. Clients MAY try again
+ later.
+
+ tp:rationale
+ For instance, the ChannelDispatcher
+ might raise this error for some or all channel requests if it has
+ detected that there is not enough free memory.
+
+
+
+
tp:copyrightCopyright © 2005-2009 Collabora Limited
tp:copyrightCopyright © 2005-2009 Nokia Corporation
http://www.w3.org/1999/xhtml">
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/src/_version.py new/telepathy-python-0.15.11/src/_version.py
--- old/telepathy-python-0.15.10/src/_version.py 2009-07-30 11:43:08.000000000 +0200
+++ new/telepathy-python-0.15.11/src/_version.py 2009-08-18 17:38:51.000000000 +0200
@@ -1,4 +1,4 @@
__all__ = ('version', '__version__')
-version = (0, 15, 10)
+version = (0, 15, 11)
__version__ = '.'.join(str(x) for x in version)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/src/server/__init__.py new/telepathy-python-0.15.11/src/server/__init__.py
--- old/telepathy-python-0.15.10/src/server/__init__.py 2009-07-22 18:29:20.000000000 +0200
+++ new/telepathy-python-0.15.11/src/server/__init__.py 2009-08-18 17:27:55.000000000 +0200
@@ -24,6 +24,7 @@
from telepathy.server.conn import *
from telepathy.server.channel import *
from telepathy.server.channelmanager import *
+from telepathy.server.debug import *
from telepathy.server.handle import *
from telepathy.server.media import *
from telepathy.server.properties import *
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/src/server/channel.py new/telepathy-python-0.15.11/src/server/channel.py
--- old/telepathy-python-0.15.10/src/server/channel.py 2009-07-22 18:29:20.000000000 +0200
+++ new/telepathy-python-0.15.11/src/server/channel.py 2009-08-18 17:26:20.000000000 +0200
@@ -31,6 +31,7 @@
CHANNEL_INTERFACE_HOLD,
CHANNEL_INTERFACE_PASSWORD,
CHANNEL_TYPE_CONTACT_LIST,
+ CHANNEL_TYPE_FILE_TRANSFER,
CHANNEL_TYPE_ROOM_LIST,
CHANNEL_TYPE_STREAMED_MEDIA,
CHANNEL_TYPE_TEXT,
@@ -145,6 +146,38 @@
def __init__(self, connection, manager, props):
"""
+ Initialise the channel.
+
+ Parameters:
+ connection - the parent Telepathy Connection object
+ """
+ Channel.__init__(self, connection, manager, props)
+
+
+from telepathy._generated.Channel_Type_File_Transfer \
+ import ChannelTypeFileTransfer as _ChannelTypeFileTransferIface
+
+class ChannelTypeFileTransfer(Channel, _ChannelTypeFileTransferIface):
+ __doc__ = _ChannelTypeFileTransferIface.__doc__
+
+ def __init__(self, connection, manager, props):
+ """
+ Initialise the channel.
+
+ Parameters:
+ connection - the parent Telepathy Connection object
+ """
+ Channel.__init__(self, connection, manager, props)
+
+
+from telepathy._generated.Channel_Type_File_Transfer \
+ import ChannelTypeFileTransfer as _ChannelTypeFileTransferIface
+
+class ChannelTypeFileTransfer(Channel, _ChannelTypeFileTransferIface):
+ __doc__ = _ChannelTypeFileTransferIface.__doc__
+
+ def __init__(self, connection, manager, props):
+ """
Initialise the channel.
Parameters:
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/src/server/conn.py new/telepathy-python-0.15.11/src/server/conn.py
--- old/telepathy-python-0.15.10/src/server/conn.py 2009-07-22 18:29:20.000000000 +0200
+++ new/telepathy-python-0.15.11/src/server/conn.py 2009-08-12 04:48:33.000000000 +0200
@@ -26,6 +26,7 @@
from telepathy.constants import (CONNECTION_STATUS_DISCONNECTED,
CONNECTION_STATUS_CONNECTED,
HANDLE_TYPE_NONE,
+ HANDLE_TYPE_CONTACT,
LAST_HANDLE_TYPE)
from telepathy.errors import (Disconnected, InvalidArgument,
InvalidHandle, NotAvailable,
@@ -335,13 +336,15 @@
@dbus.service.method(CONN_INTERFACE_CAPABILITIES, in_signature='au', out_signature='a(usuu)')
def GetCapabilities(self, handles):
ret = []
+ handle_type = HANDLE_TYPE_CONTACT
for handle in handles:
- if (handle != 0 and handle not in self._handles):
+ if (handle != 0 and (handle_type, handle) not in self._handles):
raise InvalidHandle
elif handle in self._caps:
- theirs = self._caps[handle]
- for type in theirs:
- ret.append([handle, type, theirs[0], theirs[1]])
+ types = self._caps[handle]
+ for ctype, specs in types.items():
+ ret.append([handle, ctype, specs[0], specs[1]])
+ return ret
@dbus.service.signal(CONN_INTERFACE_CAPABILITIES, signature='a(usuuuu)')
def CapabilitiesChanged(self, caps):
@@ -433,7 +436,7 @@
type = props[CHANNEL_INTERFACE + '.ChannelType']
handle_type = props.get(CHANNEL_INTERFACE + '.TargetHandleType',
HANDLE_TYPE_NONE)
- handle = props[CHANNEL_INTERFACE + '.TargetHandle']
+ handle = props.get(CHANNEL_INTERFACE + '.TargetHandle', 0)
return (type, handle_type, handle)
@@ -476,8 +479,12 @@
if target_handle_type != HANDLE_TYPE_NONE:
if target_handle == None:
# Turn TargetID into TargetHandle.
- self.check_handle(target_handle_type, target_id)
- target_handle = self._handles[target_handle_type, target_id]
+ for handle in self._handles.itervalues():
+ if handle.get_name() == target_id and handle.get_type() == target_handle_type:
+ target_handle = handle.get_id()
+ if not target_handle:
+ raise InvalidHandle('TargetID %s not valid for type %d' %
+ target_id, target_handle_type)
altered_properties[CHANNEL_INTERFACE + '.TargetHandle'] = \
target_handle
@@ -522,12 +529,12 @@
in_signature='a{sv}', out_signature='boa{sv}',
async_callbacks=('_success', '_error'))
def EnsureChannel(self, request, _success, _error):
- yours = not self._channel_manager.channel_exists(request)
-
type, handle_type, handle = self._check_basic_properties(request)
self._validate_handle(request)
props = self._alter_properties(request)
+ yours = not self._channel_manager.channel_exists(props)
+
channel = self._channel_manager.channel_for_props(props, signal=False)
_success(yours, channel._object_path, props)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/src/server/debug.py new/telepathy-python-0.15.11/src/server/debug.py
--- old/telepathy-python-0.15.10/src/server/debug.py 1970-01-01 01:00:00.000000000 +0100
+++ new/telepathy-python-0.15.11/src/server/debug.py 2009-08-18 17:27:55.000000000 +0200
@@ -0,0 +1,113 @@
+# telepathy-python - Base classes defining the interfaces of the Telepathy framework
+#
+# Copyright (C) 2009 Collabora Limited
+#
+# 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.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# 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 St, Fifth Floor, Boston, MA 02110-1301 USA
+
+from telepathy.interfaces import DEBUG
+from telepathy.constants import (DEBUG_LEVEL_ERROR,
+ DEBUG_LEVEL_CRITICAL,
+ DEBUG_LEVEL_WARNING,
+ DEBUG_LEVEL_INFO,
+ DEBUG_LEVEL_DEBUG)
+
+from telepathy._generated.Debug import Debug as _Debug
+from telepathy.server.properties import DBusProperties
+
+import dbus.service
+import logging
+import sys
+import time
+
+LEVELS = {
+ logging.ERROR: DEBUG_LEVEL_ERROR,
+ logging.FATAL: DEBUG_LEVEL_CRITICAL,
+ logging.WARNING: DEBUG_LEVEL_WARNING,
+ logging.INFO: DEBUG_LEVEL_INFO,
+ logging.DEBUG: DEBUG_LEVEL_DEBUG,
+ logging.NOTSET: DEBUG_LEVEL_DEBUG
+}
+
+DEBUG_MESSAGE_LIMIT = 800
+
+class Debug(_Debug, DBusProperties, logging.Handler):
+
+ def __init__(self, conn_manager, root=''):
+ self.enabled = True
+ self._interfaces = set()
+ self._messages = []
+ object_path = '/org/freedesktop/Telepathy/debug'
+
+ _Debug.__init__(self, conn_manager._name, object_path)
+ DBusProperties.__init__(self)
+ logging.Handler.__init__(self)
+
+ self._implement_property_get(DEBUG, {'Enabled': lambda: self.enabled})
+ logging.getLogger(root).addHandler(self)
+ sys.stderr = StdErrWrapper(self, sys.stderr)
+
+ def GetMessages(self):
+ return self._messages
+
+ def add_message(self, timestamp, name, level, msg):
+ if len(self._messages) >= DEBUG_MESSAGE_LIMIT:
+ self._messages.pop()
+ self._messages.append((timestamp, name, level, msg))
+ if self.enabled:
+ self.NewDebugMessage(timestamp, name, level, msg)
+
+ # Handle logging module messages
+
+ def emit(self, record):
+ name = self.get_record_name(record)
+ level = self.get_record_level(record)
+ self.add_message(record.created, name, level, record.msg)
+
+ def get_record_level(self, record):
+ return LEVELS[record.levelno]
+
+ def get_record_name(self, record):
+ name = record.name
+ if name.contains("."):
+ domain, category = record.name.split('.', 1)
+ name = domain + "/" + category
+ return name
+
+# Wrapper around stderr so the exceptions are logged
+
+class StdErrWrapper(object):
+
+ def __init__(self, interface, stderr):
+ self._buffer = ""
+ self._interface = interface
+ self._stderr = stderr
+
+ def __getattr__(self, attr):
+ return getattr(self._stderr, attr)
+
+ def write(self, string):
+ self._stderr.write(string)
+ if '\n' not in string:
+ self._buffer += string
+ return
+
+ lines = string.split('\n')
+ lines[0] = self._buffer + lines[0]
+ self._buffer = lines[-1]
+ del lines[-1]
+
+ timestamp = time.time()
+ for line in lines:
+ self._interface.add_message(timestamp, "stderr", DEBUG_LEVEL_ERROR, line)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/tools/python-constants-generator.xsl new/telepathy-python-0.15.11/tools/python-constants-generator.xsl
--- old/telepathy-python-0.15.10/tools/python-constants-generator.xsl 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/tools/python-constants-generator.xsl 2009-08-18 17:26:20.000000000 +0200
@@ -72,7 +72,7 @@
"""
-
+
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/telepathy-python-0.15.10/tools/python-interfaces-generator.xsl new/telepathy-python-0.15.11/tools/python-interfaces-generator.xsl
--- old/telepathy-python-0.15.10/tools/python-interfaces-generator.xsl 2009-06-12 13:34:52.000000000 +0200
+++ new/telepathy-python-0.15.11/tools/python-interfaces-generator.xsl 2009-08-18 17:26:20.000000000 +0200
@@ -28,7 +28,7 @@
"""
-
+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Remember to have fun...
--
To unsubscribe, e-mail: opensuse-commit+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-commit+help@opensuse.org