diff options
author | Jonny Lamb <jonny.lamb@collabora.co.uk> | 2010-04-07 20:20:05 +0100 |
---|---|---|
committer | Jonny Lamb <jonny.lamb@collabora.co.uk> | 2010-04-07 20:31:26 +0100 |
commit | 3fb41ef63c60dd14492e9eeaf53ca0912293cb03 (patch) | |
tree | 7bde341e588ecc6299ad5e0e614f883246219a59 | |
parent | a1b87337d8f2bacdb029f94c972b7413630da895 (diff) |
spec: update to 0.19.3
Signed-off-by: Jonny Lamb <jonny.lamb@collabora.co.uk>
-rw-r--r-- | spec/Call_Content.xml | 14 | ||||
-rw-r--r-- | spec/Call_Stream.xml | 6 | ||||
-rw-r--r-- | spec/Call_Stream_Interface_Media.xml | 2 | ||||
-rw-r--r-- | spec/Channel.xml | 23 | ||||
-rw-r--r-- | spec/Channel_Interface_Conference.xml | 52 | ||||
-rw-r--r-- | spec/Channel_Interface_Media_Signalling.xml | 20 | ||||
-rw-r--r-- | spec/Channel_Interface_Messages.xml | 130 | ||||
-rw-r--r-- | spec/Channel_Interface_Password.xml | 4 | ||||
-rw-r--r-- | spec/Channel_Type_Call.xml | 78 | ||||
-rw-r--r-- | spec/Channel_Type_Streamed_Media.xml | 60 | ||||
-rw-r--r-- | spec/Client_Observer.xml | 11 | ||||
-rw-r--r-- | spec/Connection.xml | 88 | ||||
-rw-r--r-- | spec/Connection_Interface_Contact_Capabilities.xml | 21 | ||||
-rw-r--r-- | spec/Connection_Interface_Contacts.xml | 28 | ||||
-rw-r--r-- | spec/Connection_Interface_Mail_Notification.xml | 653 | ||||
-rw-r--r-- | spec/Connection_Manager.xml | 33 | ||||
-rw-r--r-- | spec/all.xml | 9 |
17 files changed, 1077 insertions, 155 deletions
diff --git a/spec/Call_Content.xml b/spec/Call_Content.xml index 1d5e891..3e585b4 100644 --- a/spec/Call_Content.xml +++ b/spec/Call_Content.xml @@ -33,6 +33,20 @@ </tp:docstring> + <method name="Remove" tp:name-for-bindings="Remove"> + <tp:docstring>Remove the content from the call.</tp:docstring> + + <tp:possible-errors> + <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"> + </tp:error> + <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"> + <tp:docstring> + Raised when a Call doesn't support removing contents (e.g. a Google Talk video call) + </tp:docstring> + </tp:error> + </tp:possible-errors> + </method> + <property name="Name" tp:name-for-bindings="Name" type="s" access="read"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The name of the content. diff --git a/spec/Call_Stream.xml b/spec/Call_Stream.xml index 302bd5e..dc7d784 100644 --- a/spec/Call_Stream.xml +++ b/spec/Call_Stream.xml @@ -30,8 +30,10 @@ </tp:docstring> <method name="SetSending" tp:name-for-bindings="Set_Sending"> - <p>Set the stream to start or stop sending media from the local - user to other contacts.</p> + <tp:docstring> + Set the stream to start or stop sending media from the local + user to other contacts. + </tp:docstring> <arg name="Send" type="b" direction="in"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> diff --git a/spec/Call_Stream_Interface_Media.xml b/spec/Call_Stream_Interface_Media.xml index ccf9033..b1b9e19 100644 --- a/spec/Call_Stream_Interface_Media.xml +++ b/spec/Call_Stream_Interface_Media.xml @@ -385,6 +385,7 @@ <property name="Endpoints" tp:name-for-bindings="Endpoints" type="ao" access="read"> + <tp:docstring> <p> The list of endpoints <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Stream" @@ -394,6 +395,7 @@ <p>Change notification is via the <tp:member-ref>EndpointsChanged</tp:member-ref> signal.</p> + </tp:docstring> </property> </interface> </node> diff --git a/spec/Channel.xml b/spec/Channel.xml index 223a612..0fedf68 100644 --- a/spec/Channel.xml +++ b/spec/Channel.xml @@ -355,7 +355,28 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ 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 + <p>The contact who initiated the channel; for instance, the contact + who invited the local user to a chatroom, or the contact who + initiated a call.</p> + + <p>This does <em>not</em> necessarily represent the contact who + created the underlying protocol-level construct. For instance, if + Rob creates a chatroom, Will joins that chatroom, and Will invites Simon + to join it, then Simon will see Will as the InitiatorHandle of the + channel representing the chatroom.</p> + + <tp:rationale> + <p>The room creator is generally a less useful piece of information + than the inviter, is less likely to be available at invitation + time (i.e. can't necessarily be an immutable property), and is + less likely to be available at all. The creator of a chatroom + is not currently available via Telepathy; if added in future, it + is likely to be made available as a property on the Chatroom + interface (<a + href="http://bugs.freedesktop.org/show_bug.cgi?id=23151">bug 23151</a>).</p> + </tp:rationale> + + <p>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 diff --git a/spec/Channel_Interface_Conference.xml b/spec/Channel_Interface_Conference.xml index af3e627..2441a7d 100644 --- a/spec/Channel_Interface_Conference.xml +++ b/spec/Channel_Interface_Conference.xml @@ -61,7 +61,7 @@ which returns a Conference channel.</p> <p>Either of the XMPP cases could work for Call channels, to - upgrade from 1-1 Jingle to multi-user Muji. Any of the XMPP cases + upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases could in principle work for link-local XMPP (XEP-0174).</p> <p>The underlying switchboard representing an MSN 1-1 conversation C1 @@ -279,9 +279,6 @@ someone else to participate.</p> </tp:rationale> - <p>At most one of InitialInviteeHandles and InitialInviteeIDs may - appear in each request.</p> - <p>If the local user was not the initiator of this channel, the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface" >Group.SelfHandle</tp:dbus-ref> SHOULD appear in the value of this @@ -289,6 +286,36 @@ (if that information is known).</p> <p>This property is immutable.</p> + + <p>InitialInviteeHandles, InitialInviteeIDs and InitialChannels MAY be + combined in a single request.</p> + + <tp:rationale> + <p>For example, if you have a 1-1 channel C1 with Rob, and you want + to invite Sjoerd to join the discussion, you can do so by + requesting a channel with InitialChannels=[C1] and + InitialInviteeHandles=[sjoerd], + or InitialChannels=[C1] and + InitialInviteeIDs=["sjoerd@example.com"].</p> + </tp:rationale> + + <p>If a request includes some combination of InitialInviteeHandles, + InitialInviteeIDs and InitialChannels, then the value of + InitialInviteeHandles on the resulting channel SHOULD be the union of + the handles from InitialInviteeHandles, the handles corresponding + to the InitialInviteeIDs, and the target handles of the + InitialChannels, with any duplicate handles removed. Because this + property is immutable, its value SHOULD be computed before the + channel is announced via the NewChannels signal.</p> + + <tp:rationale> + <p>This simplifies identification of new channels in clients - they + only have to look at one of the properties, not both. For example, + after either of the requests mentioned above, the NewChannels + signal would announce the channel with InitialChannels=[C1], + InitialInviteeHandles=[rob, sjoerd], and + InitialInviteeIDs=["rob@example.net", "sjoerd.example.com"].</p> + </tp:rationale> </tp:docstring> </property> @@ -299,16 +326,17 @@ <p>A list of additional contacts invited to this conference when it was created.</p> - <p>This property SHOULD be requestable, as an alternative to - <tp:member-ref>InitialInviteeHandles</tp:member-ref>. Its semantics - are the same, except that it takes a list of the string - representations of contact handles.</p> - - <p>At most one of InitialInviteeHandles and InitialInviteeIDs may - appear in each request.</p> + <p>This property SHOULD be requestable as an alternative to, or + combined with, <tp:member-ref>InitialInviteeHandles</tp:member-ref>. + Its semantics are the same, except that it takes a list of the + string representations of contact handles; invitations are sent to + any contact present in either or both of these properties.</p> <p>When a channel is created, the values of InitialInviteeHandles and - InitialInviteeIDs MUST correspond to each other.</p> + InitialInviteeIDs MUST correspond to each other. In particular, this + means that the value of InitialInviteeIDs will include the TargetID + of each channel in InitialChannels, and the ID corresponding to each + handle in InitialInviteeHandles.</p> <p>This property is immutable.</p> </tp:docstring> diff --git a/spec/Channel_Interface_Media_Signalling.xml b/spec/Channel_Interface_Media_Signalling.xml index 004df5b..242c952 100644 --- a/spec/Channel_Interface_Media_Signalling.xml +++ b/spec/Channel_Interface_Media_Signalling.xml @@ -152,39 +152,39 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ </tp:docstring> </tp:property> - <tp:handler-capability-token name="gtalk-p2p"> + <tp:hct name="gtalk-p2p"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref> property is <code>gtalk-p2p</code>.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="ice-udp"> + <tp:hct name="ice-udp"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref> property is <code>ice-udp</code>.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="wlm-8.5"> + <tp:hct name="wlm-8.5"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref> property is <code>wlm-8.5</code>.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="wlm-2009"> + <tp:hct name="wlm-2009"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref> property is <code>wlm-2009</code>.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="video/h264" is-family="yes"> + <tp:hct name="video/h264" is-family="yes"> <tp:docstring> <p>The client supports media streaming with H264 (etc.).</p> @@ -228,7 +228,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ known to the gatewaying process.</p> </tp:rationale> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> </interface> </node> diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml index c668067..566e116 100644 --- a/spec/Channel_Interface_Messages.xml +++ b/spec/Channel_Interface_Messages.xml @@ -185,7 +185,7 @@ USA.</p> appears in isolation - messages are represented by a list of <tp:type>Message_Part</tp:type> mappings.</p> - <p>An example of how a message might + <p>An example of how a rich-text message, with an embedded image, might look, in a Python-like syntax:</p> <pre> @@ -213,8 +213,26 @@ USA.</p> 'size': 101000, 'needs-retrieval': True, }, -] - </pre> +]</pre> + + <p>An example of how a non-text message — in particular, a vCard sent + via SMS as implemented by telepathy-ring on Nokia's Maemo 5 — + looks:</p> + + <pre> +[ + { + 'message-token': '9de9546a-3400-4419-a505-3ea270cb834c', + 'message-sender': 42, + 'message-sent': 1210067943, + 'message-received': 1210067947, + 'message-type': 0, # = Channel_Text_Message_Type_Normal + 'pending-message-id': 437, + }, + { 'content-type': 'text/x-vcard', + 'content': [ 0x66, 0x69, 0x71, ...], # vCard data as an array of bytes + }, +]</pre> <div> <p>The first part of the message contains "headers" which refer @@ -247,10 +265,40 @@ USA.</p> <dl> <dt>message-token (s)</dt> - <dd>An opaque, globally-unique identifier for the entire message. - This MAY be treated as if it were a MIME Message-ID, e.g. for - the mid: and cid: URI schemes. If omitted, there is no suitable - token.</dd> + <dd> + <p>An opaque, globally-unique identifier for the entire message. + This MAY be treated as if it were a MIME Message-ID, e.g. for + the mid: and cid: URI schemes. If omitted, there is no suitable + token; the protocol-token key SHOULD be provided if the protocol + identifies messages in some less unique way.</p> + </dd> + + <dt>protocol-token (s - <tp:type>Protocol_Message_Token</tp:type>)</dt> + <dd> + <p>An opaque token for the entire message, with whatever uniqueness + guarantee is provided by the underlying protocol. As described + for the Protocol_Message_Token type, this token is <em>not</em> + guaranteed to be unique between contacts, or even within the + scope of a Channel.</p> + + <tp:rationale> + <p>In practice, in most protocols there is no token with the + uniqueness guarantees demanded for message-token; the + definition of message-token was inappropriate, but must now + be preserved for the benefit of clients that rely on it, at + least until Telepathy breaks backwards compatibility.</p> + </tp:rationale> + + <p>The message-token and protocol-token SHOULD NOT both be present; + clients requiring an identifier with the semantics of the + protocol-token SHOULD look for the message-token first, falling + back to the protocol-token.</p> + + <tp:rationale> + <p>This is for compatibility with CMs older than the + protocol-token key.</p> + </tp:rationale> + </dd> <dt>message-sent (x - <tp:type>Unix_Timestamp64</tp:type>)</dt> <dd>The time the message was sent (if unavailable, the time @@ -426,7 +474,33 @@ USA.</p> There's no point in providing the size if you're already providing all the content. </tp:rationale> - </dd> + </dd> + + <dt>thumbnail (b)</dt> + <dd> + <p>This part is a thumbnail. To represent an image together with + its thumbnail in a single message, there should be one part for + the full image followed by a part for the thumbnail (following + the “more complete versions first” requirement), with the same + 'alternative' value. For example:</p> + + <pre> +[ ... , + { 'alternative': 'catphoto', + 'content-type': 'image/jpeg', + 'size': 150000, + 'content': [0xFF, 0xD8, ... 0xFF 0xD9], + }, + { 'alternative': 'catphoto', + 'content-type': 'image/jpeg' + 'size': 1024, + 'thumbnail': True, + 'content': [0xFF, 0xD8, ... 0xFF 0xD9], + }, + ... +] + </pre> + </dd> <dt>needs-retrieval (b)</dt> <dd>If false or omitted, the connection @@ -504,7 +578,7 @@ USA.</p> <dd>The status of the message. All delivery reports MUST contain this key in the first Message_Part.</dd> - <dt>delivery-token (s - Sent_Message_Token)</dt> + <dt>delivery-token (s - <tp:type>Protocol_Message_Token</tp:type>)</dt> <dd> <p>An identifier for the message to which this delivery report @@ -740,22 +814,27 @@ USA.</p> </tp:member> </tp:mapping> - <tp:simple-type type="s" name="Sent_Message_Token"> + <tp:simple-type type="s" name="Protocol_Message_Token"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> - <p>An opaque token used to identify sent messages. As a special case, - the empty string indicates that there is no particular - identification for a message.</p> + <p>An opaque token used to identify messages in the underlying. + protocol. As a special case, the empty string indicates that there + is no particular identification for a message.</p> <p>CM implementations SHOULD use an identifier expected to be unique, such as a UUID, if possible.</p> - <p>Some protocols can only track a limited number of sent messages - in a small message-ID space. As a result, clients MUST NOT assume - that message tokens will not be re-used, and SHOULD use some - reasonable heuristic to assign delivery reports to messages, such - as matching on message content or timestamp (if available), or - assuming that the delivery report refers to the most recent message - with that ID.</p> + <p>Some protocols can only track a limited number of messages + in a small message-ID space (SMS messages are identified by a single + byte), and some implementations send non-unique identifiers (some + XMPP clients use very simple message IDs, such as an incrementing + integer that resets to 1 at the beginning of each connection). As a + result, clients MUST NOT assume that protocol tokens will not be + re-used.</p> + + <p>In particular, clients SHOULD use a heuristic to assign delivery + reports to messages, such as matching on message content or + timestamp (if available), or assuming that the delivery report + refers to the most recent message with that ID.</p> </tp:docstring> </tp:simple-type> @@ -774,7 +853,7 @@ USA.</p> <tp:rationale> <p>This means that the process sending the message is the first - to see the <tp:type>Sent_Message_Token</tp:type>, and can + to see the <tp:type>Protocol_Message_Token</tp:type>, and can relate the message to the corresponding <tp:member-ref>MessageSent</tp:member-ref> signal by comparing message tokens (if supported by the protocol).</p> @@ -798,7 +877,7 @@ USA.</p> </tp:docstring> </arg> - <arg direction="out" type="s" tp:type="Sent_Message_Token" + <arg direction="out" type="s" tp:type="Protocol_Message_Token" name="Token"> <tp:docstring> An opaque token used to match any incoming delivery or failure @@ -850,8 +929,9 @@ USA.</p> <p>Signals that a message has been submitted for sending. This MUST be emitted exactly once per emission of the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type.Text">Sent</tp:dbus-ref> - signal on the - Text interface.</p> + signal on the Text interface. This SHOULD be emitted as soon as + the CM determines it's theoretically possible to send the message + (e.g. the parameters are supported and correct).</p> <tp:rationale> <p>This signal allows a process that is not the caller of @@ -889,7 +969,7 @@ USA.</p> </tp:docstring> </arg> - <arg name="Message_Token" type="s" tp:type="Sent_Message_Token"> + <arg name="Message_Token" type="s" tp:type="Protocol_Message_Token"> <tp:docstring> An opaque token used to match any incoming delivery or failure reports against this message, or an empty string if the message diff --git a/spec/Channel_Interface_Password.xml b/spec/Channel_Interface_Password.xml index 76720a6..4e201dd 100644 --- a/spec/Channel_Interface_Password.xml +++ b/spec/Channel_Interface_Password.xml @@ -73,7 +73,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. </tp:docstring> </arg> <arg direction="out" type="b" name="Correct"> - A boolean indicating whether or not the password was correct + <tp:docstring> + A boolean indicating whether or not the password was correct + </tp:docstring> </arg> <tp:docstring> Provide the password so that the channel can be joined. Must be diff --git a/spec/Channel_Type_Call.xml b/spec/Channel_Type_Call.xml index 702eb17..dacf906 100644 --- a/spec/Channel_Type_Call.xml +++ b/spec/Channel_Type_Call.xml @@ -40,7 +40,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel" >Requested</tp:dbus-ref> property is false, and the <tp:member-ref>CallState</tp:member-ref> is - Call_State_Pending_Initiator. While this is the case, + Call_State_Pending_Receiver. While this is the case, this method SHOULD change the <tp:member-ref>CallFlags</tp:member-ref> to include Call_Flag_Ringing, and notify the remote contact that the local @@ -61,7 +61,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. </tp:error> <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"> <tp:docstring> - The call is no longer in state Call_State_Pending_Initiator. + The call is no longer in state Call_State_Pending_Receiver. </tp:docstring> </tp:error> </tp:possible-errors> @@ -737,26 +737,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. <tp:rationale><p>This reduces D-Bus round trips.</p></tp:rationale> - <p>Connection managers capable of signalling audio calls to contacts - SHOULD include a channel class in <tp:dbus-ref - namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref> - with <tp:dbus-ref - namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref> - <tp:dbus-ref - namespace="org.freedesktop.Telepathy.Channel.Type">Call.DRAFT</tp:dbus-ref> - and <tp:dbus-ref - namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref> - = Contact in the fixed properties dictionary, and InitialAudio - (and also InitialVideo, if applicable) in the allowed properties - list. Clients wishing to discover whether a connection manager - can signal audio and/or video calls SHOULD use this information.</p> - - <tp:rationale> - <p>Not all protocols support signalling video calls, and it would be - possible (although unlikely) to have a protocol where only video, - and not audio, could be signalled.</p> - </tp:rationale> - <p>Connection managers that support the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities</tp:dbus-ref> interface SHOULD represent the capabilities of receiving audio @@ -848,40 +828,52 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. </tp:docstring> </property> - <tp:handler-capability-token name="gtalk-p2p"> + <tp:hct name="audio"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>This client supports audio calls.</p> + </tp:docstring> + </tp:hct> + + <tp:hct name="video"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>This client supports video calls.</p> + </tp:docstring> + </tp:hct> + + <tp:hct name="gtalk-p2p"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref> property is Stream_Transport_Type_GTalk_P2P.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="ice"> + <tp:hct name="ice"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref> property is Stream_Transport_Type_ICE.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="wlm-8.5"> + <tp:hct name="wlm-8.5"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref> property is Stream_Transport_Type_WLM_8_5.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="wlm-2009"> + <tp:hct name="wlm-2009"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client can implement streaming for streams whose <tp:dbus-ref namespace="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref> property is Stream_Transport_Type_WLM_2009.</p> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> - <tp:handler-capability-token name="video/h264" is-family="yes"> - <tp:docstring> + <tp:hct name="video/h264" is-family="yes"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>The client supports media streaming with H264 (etc.).</p> <p>This handler capability token is a one of a family @@ -904,15 +896,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. <code>video/h264</code> on Call channels.</p> </tp:rationale> - <p>For example, a client could advertise support for - Speex, Theora and H264 by having three - handler capability tokens, - <code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio/speex</code>, - <code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/theora</code> and - <code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/h264</code>, - in its <tp:dbus-ref + <p>For example, a client could advertise support for audio and video + calls using Speex, Theora and H264 by having five handler capability + tokens in its <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Handler">Capabilities</tp:dbus-ref> - property.</p> + property:</p> + + <ul> + <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio</code></li> + <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio/speex</code></li> + <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video</code></li> + <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/theora</code></li> + <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/h264</code></li> + </ul> <p>Clients MAY have media signalling abilities without explicitly supporting any particular codec, and connection managers SHOULD @@ -924,7 +920,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. known to the gatewaying process.</p> </tp:rationale> </tp:docstring> - </tp:handler-capability-token> + </tp:hct> </interface> </node> diff --git a/spec/Channel_Type_Streamed_Media.xml b/spec/Channel_Type_Streamed_Media.xml index 4c651cd..4484b7c 100644 --- a/spec/Channel_Type_Streamed_Media.xml +++ b/spec/Channel_Type_Streamed_Media.xml @@ -144,7 +144,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"> - A stream identifier is unknown + <tp:docstring> + A stream identifier is unknown + </tp:docstring> </tp:error> </tp:possible-errors> </method> @@ -183,10 +185,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ </tp:docstring> <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"> - A stream identifier is unknown + <tp:docstring> + A stream identifier is unknown + </tp:docstring> </tp:error> <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"> - The requested direction is not available on this stream + <tp:docstring> + The requested direction is not available on this stream + </tp:docstring> </tp:error> </tp:possible-errors> </method> @@ -660,6 +666,54 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ handled by specialised hardware which is controlled directly by the connection manager), the signalling interface can be omitted and this channel type used simply to control the streams.</p> + + <h4>Handler filters</h4> + + <p>For historical reasons, handlers must specify more than one filter if + they want to correctly advertise support for audio and/or video calls. If + they can handle channels using the <tp:dbus-ref + namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling</tp:dbus-ref> + interface, they should also advertise various + <tp:type>Handler_Capability_Token</tp:type>s to indicate which codecs and + transports they support. See <tp:member-ref>InitialAudio</tp:member-ref> + and <tp:dbus-ref + namespace="org.freedesktop.Telepathy.Channel.Interface">MediaSignalling/video/h264</tp:dbus-ref> + for the gory details. In summary:</p> + + <dl> + <dt>To advertise support for streamed media in general, include the + following filter in <tp:dbus-ref + namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>:</dt> + <dd><pre> +{ '...Channel.Type': '...Channel.Type.StreamedMedia' , + '...Channel.TargetHandleType': Contact, +}</pre></dd> + + <dt>To advertise support for audio calls, also include the following + filter:</dt> + <dd><pre> +{ '...Channel.Type': '...Channel.Type.StreamedMedia' , + '...Channel.TargetHandleType': Contact, + '...Channel.Type.StreamedMedia.InitialAudio': True, +}</pre></dd> + + <dt>To advertise support for video calls, also include the following + filter:</dt> + <dd><pre> +{ '...Channel.Type': '...Channel.Type.StreamedMedia' , + '...Channel.TargetHandleType': Contact, + '...Channel.Type.StreamedMedia.InitialVideo': True, +}</pre></dd> + + <dt>If you use telepathy-farsight, and have H.264 support, you probably + want these <tp:dbus-ref + namespace="org.freedesktop.Telepathy.Client.Handler">Capabilities</tp:dbus-ref>:</dt> + <dd><pre> +[ "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp", + "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/gtalk-p2p", + "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264", +]</pre></dd> + </dl> </tp:docstring> <tp:flags name="Channel_Media_Capabilities" value-prefix="Channel_Media_Capability" type="u"> diff --git a/spec/Client_Observer.xml b/spec/Client_Observer.xml index 026db52..35e6d91 100644 --- a/spec/Client_Observer.xml +++ b/spec/Client_Observer.xml @@ -147,15 +147,16 @@ <p>For observers that have a .client file, the channel dispatcher may discover this property from keys of the form - <code><em>propertyname</em>/<em>type</em></code>, + "<code><em>propertyname</em> <em>type</em></code>", in groups in the .client file whose name is the name of this interface followed by <code>.ObserverChannelFilter</code>, a space and an ASCII decimal number starting from 0.</p> - <p>Integers in the .client file are encoded in ASCII decimal, booleans - are encoded as "true" or "false", and strings are encoded in the usual - way for desktop files (including the C-style backslash escapes - documented in the Desktop Entry specification).</p> + <p>Values in the .client file are encoded in exactly the same way as + the <code>default-<em>p</em></code> keys in .manager files, as + described in the <tp:dbus-ref namespace="org.freedesktop.Telepathy" + >ConnectionManager</tp:dbus-ref> interface (but note that not all + types supported in .manager files can appear in .client files).</p> <p>For instance, a .client file for an observer that is only interested in Text channels, with CONTACT or ROOM handles, that were requested by diff --git a/spec/Connection.xml b/spec/Connection.xml index aa885c9..3109670 100644 --- a/spec/Connection.xml +++ b/spec/Connection.xml @@ -66,20 +66,14 @@ USA.</p> </tp:docstring> </method> - <method name="GetInterfaces" tp:name-for-bindings="Get_Interfaces"> - <arg direction="out" type="as" tp:type="DBus_Interface[]" - name="Interfaces"> - <tp:docstring> - An array of D-Bus interface names - </tp:docstring> - </arg> - + <property name="Interfaces" tp:name-for-bindings="Interfaces" + access="read" type="as" tp:type="DBus_Interface[]"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> - <p>Get the optional interfaces supported by this connection. - Before the connection status changes to CONNECTED, the return - from this method may change at any time, but it is guaranteed that + <p>The set of optional interfaces supported by this connection. + Before the connection status changes to CONNECTED, + this property may change at any time, but it is guaranteed that interfaces will only be added, not removed. After the connection - status changes to CONNECTED, the return from this method cannot + status changes to CONNECTED, this property cannot change further.</p> <p>There is no explicit change notification; reasonable behaviour @@ -97,6 +91,24 @@ USA.</p> interfaces for the remainder of the Connection's lifetime.</p> </tp:rationale> </tp:docstring> + <tp:added version="0.19.2">Clients SHOULD fall back + to calling <tp:member-ref>GetInterfaces</tp:member-ref> if this + property is not supported.</tp:added> + </property> + + <method name="GetInterfaces" tp:name-for-bindings="Get_Interfaces"> + <arg direction="out" type="as" tp:type="DBus_Interface[]" + name="Interfaces"> + <tp:docstring> + The value of the <tp:member-ref>Interfaces</tp:member-ref> property + </tp:docstring> + </arg> + + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>Returns the set of optional interfaces supported by this + connection. See <tp:member-ref>Interfaces</tp:member-ref> for more + details.</p> + </tp:docstring> <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"> @@ -178,11 +190,28 @@ USA.</p> </tp:possible-errors> </method> + <property name="Status" tp:name-for-bindings="Status" + access="read" type="u" tp:type="Connection_Status"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>The current status of the connection. Change notification is via + the <tp:member-ref>StatusChanged</tp:member-ref> signal.</p> + + <p>If retrieval of property succeeds and yields the value Disconnected, + this indicates that the connection has not yet been established. + If connection has been attempted and failed, the Connection object + SHOULD be removed from the bus entirely, meaning that retrieval of + this property SHOULD fail.</p> + </tp:docstring> + <tp:added version="0.19.2">Clients SHOULD fall back + to calling <tp:member-ref>GetStatus</tp:member-ref> if this + property is not supported.</tp:added> + </property> + <method name="GetStatus" tp:name-for-bindings="Get_Status"> <arg direction="out" type="u" tp:type="Connection_Status" name="Status"> <tp:docstring> - An integer representing the current status + The value of the <tp:member-ref>Status</tp:member-ref> property </tp:docstring> </arg> @@ -228,10 +257,14 @@ USA.</p> <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"> - The handle type is invalid + <tp:docstring> + The handle type is invalid + </tp:docstring> </tp:error> <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"> - One of the given handles is not valid + <tp:docstring> + One of the given handles is not valid + </tp:docstring> </tp:error> </tp:possible-errors> </method> @@ -263,10 +296,14 @@ USA.</p> <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"> - The handle type is invalid + <tp:docstring> + The handle type is invalid + </tp:docstring> </tp:error> <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"> - One of the given handles is not valid + <tp:docstring> + One of the given handles is not valid + </tp:docstring> </tp:error> </tp:possible-errors> </method> @@ -649,20 +686,25 @@ USA.</p> <tp:enum name="Connection_Status" plural="Connection_Statuses" type="u"> <tp:enumvalue suffix="Connected" value="0"> <tp:docstring> - The connection is alive and all methods are available. + The connection is fully connected and all methods are available. </tp:docstring> </tp:enumvalue> <tp:enumvalue suffix="Connecting" value="1"> <tp:docstring> - The connection has not yet been established, or has been - severed and reconnection is being attempted. Some methods may fail - until the connection has been established. + <tp:member-ref>Connect</tp:member-ref> has been called but the + connection has not yet been established. Some methods may fail + until the connection has been established. </tp:docstring> </tp:enumvalue> <tp:enumvalue suffix="Disconnected" value="2"> <tp:docstring> - The connection has been severed and no method calls are - valid. The object may be removed from the bus at any time. + If this is retrieved from <tp:member-ref>GetStatus</tp:member-ref> or + <tp:member-ref>Status</tp:member-ref>, it indicates that connection + has not yet been attempted. If seen in a + <tp:member-ref>StatusChanged</tp:member-ref> signal, it indicates + that the connection has failed; the Connection object SHOULD be + removed from D-Bus immediately, and all subsequent method calls + SHOULD fail. </tp:docstring> </tp:enumvalue> </tp:enum> diff --git a/spec/Connection_Interface_Contact_Capabilities.xml b/spec/Connection_Interface_Contact_Capabilities.xml index 803ab06..fb13c37 100644 --- a/spec/Connection_Interface_Contact_Capabilities.xml +++ b/spec/Connection_Interface_Contact_Capabilities.xml @@ -161,7 +161,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <method name="GetContactCapabilities" tp:name-for-bindings="Get_Contact_Capabilities"> - <arg direction="in" name="handles" type="au" tp:type="Contact_Handle[]"> + <arg direction="in" name="Handles" type="au" tp:type="Contact_Handle[]"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>An array of contact handles for this connection.</p> @@ -171,15 +171,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <arg direction="out" type="a{ua(a{sv}as)}" tp:type="Contact_Capabilities_Map" name="Contact_Capabilities"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> - An array of structures containing: - <ul> - <li>a dictionary mapping the channel properties to their values.</li> - <li>an array of additional allowed properties</li> - </ul> + <p>A map from contact handles to lists of requestable channel + classes, representing the channel requests that are expected + to succeed for that contact.</p> + + <p>Contacts listed among Handles whose capabilities are unknown + SHOULD be omitted from this map; contacts known to have an empty + set of capabilities SHOULD be included in the keys of this map, + with an empty array as the corresponding value.</p> </tp:docstring> </arg> - <tp:docstring> - Returns an array of enhanced capabilities for the given contact handles. + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>Returns an array of requestable channel classes for the given + contact handles, representing the channel requests that are + expected to succeed.</p> </tp:docstring> <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> diff --git a/spec/Connection_Interface_Contacts.xml b/spec/Connection_Interface_Contacts.xml index 92c80c8..cd769ce 100644 --- a/spec/Connection_Interface_Contacts.xml +++ b/spec/Connection_Interface_Contacts.xml @@ -111,16 +111,18 @@ interfaces, whose values can be obtained without additional network activity, will be in the reply.</p> - <p>It is an error to request interfaces that are not supported by - this Connection (i.e. mentioned in the + <p>Connection managers SHOULD ignore interfaces requested which they + do not support (i.e. those not mentioned in the <tp:member-ref>ContactAttributeInterfaces</tp:member-ref> - property).</p> + property.)</p> <tp:rationale> - <p>This makes it possible to distinguish between interfaces for - which the Connection has nothing to say (e.g. we don't know the - avatar tokens of any of the contacts, so we omitted them all), - and interfaces for which this API isn't supported.</p> + <p>This simplifies client-side code. Clients which care may + distinguish between unsupported interfaces (e.g. this Connection + does not support Avatars), and interfaces on which no information + is known for these contacts (e.g. we don't know the avatar tokens + of any of the contacts, so we omitted them all) by inspecting + <tp:member-ref>ContactAttributeInterfaces</tp:member-ref>.</p> </tp:rationale> <p>Attributes from the interface @@ -141,6 +143,12 @@ attributes. </tp:rationale> </tp:docstring> + <tp:changed version="0.19.2"> + requesting information for interfaces not mentioned in + <tp:member-ref>ContactAttributeInterfaces</tp:member-ref> is no + longer an error. Be aware that older connection managers may still + consider this an error. + </tp:changed> </arg> <arg direction="in" name="Hold" type="b"> @@ -173,12 +181,6 @@ <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> - <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"> - <tp:docstring> - One of the requested interfaces is not supported (mentioned in - <tp:member-ref>ContactAttributeInterfaces</tp:member-ref>). - </tp:docstring> - </tp:error> </tp:possible-errors> </method> </interface> diff --git a/spec/Connection_Interface_Mail_Notification.xml b/spec/Connection_Interface_Mail_Notification.xml new file mode 100644 index 0000000..35678c2 --- /dev/null +++ b/spec/Connection_Interface_Mail_Notification.xml @@ -0,0 +1,653 @@ +<?xml version="1.0" ?> +<node name="/Connection_Interface_Mail_Notification" + xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0" + > + <tp:copyright> Copyright (C) 2007 Collabora Limited </tp:copyright> + <tp:license xmlns="http://www.w3.org/1999/xhtml"> + <p>This library is free software; you can redistribute it and/or +modify it under the terms of the GNU Lesser General Public +License as published by the Free Software Foundation; either +version 2.1 of the License, or (at your option) any later version.</p> + +<p>This library is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +Library General Public License for more details.</p> + +<p>You should have received a copy of the GNU Lesser General Public +License along with this library; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p> + </tp:license> + <interface + name="org.freedesktop.Telepathy.Connection.Interface.MailNotification.DRAFT" + tp:causes-havoc="experimental"> + <tp:requires interface="org.freedesktop.Telepathy.Connection"/> + <tp:added version="0.19.1">(as draft 1)</tp:added> + + <tp:flags name="Mail_Notification_Flags" value-prefix="Mail_Notification_Flag" type="u" > + <tp:flag suffix="Supports_Unread_Mail_Count" value="1"> + <tp:docstring> + This Connection provides the number of unread e-mails (or e-mail + threads) in the main folder of your e-mail account, as the + <tp:member-ref>UnreadMailCount</tp:member-ref> property. The + connection manager will update this value by emitting the + <tp:member-ref>UnreadMailsChanged</tp:member-ref> signal. + </tp:docstring> + </tp:flag> + <tp:flag suffix="Supports_Unread_Mails" value="2"> + <tp:docstring> + This Connection provides a detailed list of unread e-mails, as the + <tp:member-ref>UnreadMails</tp:member-ref> property. If this flag + is set, <tt>Supports_Unread_Mail_Count</tt> MUST be set, and + <tt>Emits_Mails_Received</tt> MUST NOT be set. + The Connection will update the list by emitting the + <tp:member-ref>UnreadMailsChanged</tp:member-ref> signals. + </tp:docstring> + </tp:flag> + <tp:flag suffix="Emits_Mails_Received" value="4"> + <tp:docstring> + This Connection emits the <tp:member-ref>MailsReceived</tp:member-ref> + signal, which provides details about newly arrived e-mails but does + not maintain their read/unread status afterwards. This flag MUST NOT + be combined with <tt>Supports_Unread_Mails</tt>. + </tp:docstring> + </tp:flag> + <tp:flag suffix="Supports_Request_Inbox_URL" value="8"> + <tp:docstring> + This Connection can provide a URL (with optional POST data) to + open the the inbox of the e-mail account in a web-based client, via + the <tp:member-ref>RequestInboxURL</tp:member-ref> method. + </tp:docstring> + </tp:flag> + <tp:flag suffix="Supports_Request_Mail_URL" value="16"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>This Connection can provide a URL (with optional POST data) to open + a specific mail in a web-based client, via the + <tp:member-ref>RequestMailURL</tp:member-ref> method. This feature + is not useful unless either Emits_Mails_Received or + Supports_Unread_Mails is set.</p> + + <p>If this flag is not set, clients SHOULD fall back to using + <tp:member-ref>RequestInboxURL</tp:member-ref> if available.</p> + </tp:docstring> + </tp:flag> + <tp:flag suffix="Thread_Based" value="32"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>Each <tp:type>Mail</tp:type> represents a thread of e-mails, which + MAY have more than one sender.</p> + + <tp:rationale> + <p>Google Talk notifies users about new mail in terms of unread + threads, rather than unread e-mails.</p> + </tp:rationale> + </tp:docstring> + </tp:flag> + + <tp:docstring> + <p>Flags representing capabilities provided by a connection manager. + Those values can be used as bitfield. Some flags depend on, or + conflict with, each other.</p> + + <p>Connections SHOULD implement as many of these features as the + underlying protocol allows, preferring to implement + Supports_Unread_Mails instead of Emits_Mails_Received if both are + possible.</p> + </tp:docstring> + </tp:flags> + + <tp:enum name="HTTP_Method" type="u"> + <tp:enumvalue suffix="Get" value="0"> + <tp:docstring> + Use the GET method when opening the URL. + </tp:docstring> + </tp:enumvalue> + <tp:enumvalue suffix="Post" value="1"> + <tp:docstring> + Use the POST method when opening the URL. Refer to + <tp:type>HTTP_Post_Data</tp:type> for more details. + </tp:docstring> + </tp:enumvalue> + <tp:docstring> + The HTTP Method with which to request a URL. + </tp:docstring> + </tp:enum> + + <tp:struct name="HTTP_Post_Data" array-name="HTTP_Post_Data_List"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>A pair (key, value) representing POST data compatible with the + application/x-www-form-urlencoded MIME type. The strings MUST be + valid UTF-8 strings, and the characters used in the key MUST obey + the requirements of the + <a href="http://www.w3.org/TR/html401/types.html#type-cdata"> + HTML CDATA type</a>. The value MUST NOT be + encoded with HTML entities.</p> + + <p>For example, if the POST data should contain a key "less-than" with value + "<", and a key "percent" with value "%", this should be represented as + two HTTP_Post_Data structures, ("less-than", "<") and ("percent", "%"), + resulting in a POST request whose request body is "less-than=&lt;&percent=%25". + If a client passes this to a browser by writing it into an HTML form, it + could do so by representing it as:</p> + + <pre> + <input type="hidden" name="less-than">&lt;</input> + <input type="hidden" name="percent">%</input> + </pre> + + <tp:rationale> + <p>This data can be used to generate a HTML file that will + automatically load the URL with appropriate POST data, in which case + the client MUST convert any characters that are special within HTML + into HTML entities. Alternatively, it can be used in an API that will + instruct the browser how to load the URL (like the Netscape Plug-in + API), in which case the client MUST escape + <a href="http://www.ietf.org/rfc/rfc1738.txt">characters that are + reserved in URLs</a>, if appropriate for that API.</p> + + <p>An array of pairs is used instead of a map from keys to values, + because it's valid to repeat keys in both HTML and + x-www-form-urlencoded data.</p> + </tp:rationale> + </tp:docstring> + <tp:member type="s" name="Key"> + <tp:docstring>The key, corresponding to a HTML control + name</tp:docstring> + </tp:member> + <tp:member type="s" name="Value"> + <tp:docstring>The value</tp:docstring> + </tp:member> + </tp:struct> + + <tp:struct name="Mail_Address" array-name="Mail_Address_List"> + <tp:docstring> + A pair (name, address) representing an e-mail address, + such as ("Nicolas Dufresne", "nicolas.dufresne@collabora.co.uk"). + </tp:docstring> + <tp:member type="s" name="Name"> + <tp:docstring>The displayed name corresponding to the e-mail + address</tp:docstring> + </tp:member> + <tp:member type="s" name="Address"> + <tp:docstring>The actual e-mail address</tp:docstring> + </tp:member> + </tp:struct> + + <tp:struct name="Mail_URL"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>A structure containing the required information to open a web-based + e-mail UI, without needing re-authentication (if possible).</p> + + <p>Because the URL and POST data frequently contain short-lived + credential tokens, a new URL should be requested (by calling one of + the methods that returns a Mail_URL) for each visit to the web-based + UI, and the URL should be visited soon after it is returned.</p> + </tp:docstring> + <tp:member type="s" name="URL"> + <tp:docstring> + The URL to which to send a request. + </tp:docstring> + </tp:member> + <tp:member type="u" name="Method" tp:type="HTTP_Method"> + <tp:docstring> + The HTTP method of the request. + </tp:docstring> + </tp:member> + <tp:member type="a(ss)" name="Post_Data" tp:type="HTTP_Post_Data[]"> + <tp:docstring> + An array of name-value pairs containing the POST data to use when + opening the URL. This MUST be an empty array if the Method is not + POST. + </tp:docstring> + </tp:member> + </tp:struct> + + <tp:mapping name="Mail" array-name="Mail_List"> + <tp:docstring> + An extensible map representing a mail, or (on protocols where + <tt>Thread_Based</tt> appears in + <tp:member-ref>MailNotificationFlags</tp:member-ref>) a thread of + mails. All keys are optional where not otherwise stated; however, at + least one of "senders" and "subject" must be included. + </tp:docstring> + + <tp:member type="s" name="Key"> + <tp:docstring> + <p>A key providing information about the mail or thread. Well-known + keys are as follows:</p> + + <dl> + <dt>id — s</dt> + <dd> + <p>A unique ID for this e-mail. CMs with + <tt>Supports_Unread_Mails</tt> set in + <tp:member-ref>MailNotificationFlags</tp:member-ref> MUST provide + this key in each <tp:type>Mail</tp:type>.</p> + + <p>If provided, the ID SHOULD be unique to a Mail at least until + that mail is removed with the + <tp:member-ref>UnreadMailsChanged</tp:member-ref> signal + (in protocols with <tt>Supports_Unread_Emails</tt>), or + unique for the duration of a session (otherwise).</p> + + <tp:rationale> + <p>In protocols with Supports_Unread_Mails, this key is used to + indicate which mail was removed. In protocols without that + feature, it's impossible to tell when a mail has been removed + (and hence how long the identifier will remain valid for use + with <tp:member-ref>RequestMailURL</tp:member-ref>).</p> + </tp:rationale> + </dd> + + <dt>url-data — any type</dt> + <dd>An opaque identifier (typically a string or list of strings) + provided to the Connection when calling + <tp:member-ref>RequestMailURL</tp:member-ref>, + containing information used by the Connection to build the URL. + </dd> + + <dt>senders — a(ss) (<tp:type>Mail_Address</tp:type>)</dt> + <dd> + An array of sender display name and e-mail address pairs. Note that + only e-mails represented as a thread can have multiple senders. + </dd> + + <dt>to-addresses — a(ss) (<tp:type>Mail_Address</tp:type>)</dt> + <dd> + An array of display name and e-mail address pairs representing + the recipients. + </dd> + + <dt>cc-addresses — a(ss) (<tp:type>Mail_Address</tp:type>)</dt> + <dd> + An array of display name and e-mail address pairs representing + the carbon-copy recipients. + </dd> + + <dt>sent-timestamp — x (<tp:type>Unix_Timestamp64</tp:type>)</dt> + <dd>A UNIX timestamp indicating when the message was sent, or for + a thread, when the most recent message was sent. + </dd> + + <dt>received-timestamp — x (<tp:type>Unix_Timestamp64</tp:type>)</dt> + <dd>A UNIX timestamp indicating when the message was received, or for + a thread, when the most recent message was received. + </dd> + + <dt>has-attachments — b</dt> + <dd>If true, this mail has attachments.</dd> + + <dt>subject — s</dt> + <dd> + The subject of the message. This MUST be encoded in UTF-8. + </dd> + + <dt>content-type — s</dt> + <dd> + <p>The MIME type of the message content. Two types are currently + supported: "text/plain" for plain text, and "text/html" for a + HTML document. If omitted, "text/plain" MUST be assumed. + Regardless of MIME type, the content MUST be valid UTF-8 (which + may require that the Connection transcodes it from a legacy + encoding).</p> + + <tp:rationale> + <p>All strings on D-Bus must be UTF-8.</p> + </tp:rationale> + </dd> + + <dt>truncated — b</dt> + <dd> + If true, the content is only a partial message; if false or + omitted, the content is the entire message. + </dd> + + <dt>content — s</dt> + <dd> + The body of the message, possibly truncated, encoded as appropriate + for "content-type". + </dd> + + <dt>folder — s</dt> + <dd> + The name of the folder containing this e-mails. + If omitted, the inbox SHOULD be assumed. + </dd> + </dl> + </tp:docstring> + </tp:member> + + <tp:member name="Value" type="v"> + <tp:docstring>The value, of whatever type is appropriate for the + key.</tp:docstring> + </tp:member> + </tp:mapping> + + <property name="MailNotificationFlags" type="u" access="read" + tp:type="Mail_Notification_Flags" + tp:name-for-bindings="Mail_Notification_Flags"> + <tp:docstring> + Integer representing the bitwise-OR of supported features for e-mails + notification on this server. This property MUST NOT change after the + Connection becomes CONNECTED. + + <tp:rationale> + This property indicates the behavior and availability + of the other properties and signals within this interface. A + connection manager that cannot at least set one of the flags + in the <tp:type>Mail_Notification_Flags</tp:type> + SHOULD NOT provide this interface. + </tp:rationale> + </tp:docstring> + </property> + + <property name="UnreadMailCount" type="u" access="read" + tp:name-for-bindings="Unread_Mail_Count"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>The number of unread messages in the Inbox. Change notification is + via <tp:member-ref>UnreadMailsChanged</tp:member-ref>.</p> + + <p>This property is only useful if <tt>Supports_Unread_Mail_Count</tt> + is set in the <tp:member-ref>MailNotificationFlags</tp:member-ref>; + otherwise, it MUST be zero.</p> + + <p>If <tt>Thread_Based</tt> appears in the + <tp:member-ref>MailNotificationFlags</tp:member-ref>, this property + counts the number of threads, not the number of mails.</p> + </tp:docstring> + </property> + + <property name="UnreadMails" type="aa{sv}" tp:type="Mail[]" + tp:name-for-bindings="Unread_Mails" access="read"> + <tp:docstring> + A array of unread <tp:type>Mail</tp:type>s. Change notification is via + <tp:member-ref>UnreadMailsChanged</tp:member-ref>. This property is + only useful if <tt>Supports_Unread_Mails</tt> is set in + <tp:member-ref>MailNotificationFlags</tp:member-ref>; otherwise, it MUST be + an empty list. + </tp:docstring> + </property> + + <property name="MailAddress" type="s" + tp:name-for-bindings="Mail_Address" access="read"> + <tp:docstring> + A string representing the e-mail address of the account. The CMs MUST + provide this information. + <tp:rationale> + In close integration of MailNotification with other e-mail services, + the e-mail address can be used has a unique identifier for the + account. Possible integration could be between Telepathy and + Evolution where the e-mail address is the common information in + both interfaces. + </tp:rationale> + </tp:docstring> + </property> + + <signal name="MailsReceived" tp:name-for-bindings="Mails_Received"> + <arg name="Mails" type="aa{sv}" tp:type="Mail[]"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>An array of <tp:type>Mail</tp:type>s. Those e-mail MUST NOT have + the "id" key.</p> + + <tp:rationale> + <p>On connections that emit this signal, it's impossible to tell + when a mail has been removed, and hence when "id" has become + invalid.</p> + </tp:rationale> + </tp:docstring> + </arg> + + <tp:docstring> + Emitted when new e-mails messages arrive to the inbox associated with + this connection. This signal is used for protocols that are not able + to maintain the <tp:member-ref>UnreadMails</tp:member-ref> list, but + do provide real-time notification about newly arrived e-mails. It MUST + NOT be emitted unless <tt>Emits_Mails_Received</tt> is set in + <tp:member-ref>MailNotificationFlags</tp:member-ref>. + </tp:docstring> + </signal> + + <signal name="UnreadMailsChanged" + tp:name-for-bindings="Unread_Mails_Changed"> + <arg name="Count" type="u"> + <tp:docstring> + Number of unread messages in the inbox (the new value of + <tp:member-ref>UnreadMailCount</tp:member-ref>). + </tp:docstring> + </arg> + <arg name="Mails_Added" type="aa{sv}" tp:type="Mail[]"> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>A list of <tp:type>Mail</tp:type> that are being added or updated + in <tp:member-ref>UnreadMails</tp:member-ref>.</p> + + <tp:rationale> + <p>Mails may be updated when the URL information (URL and POST data) + have changed, or senders were added or removed from an e-mail + thread.</p> + </tp:rationale> + + <p>If the <tt>Supports_Unread_Mails</tt> flag is not set, this list + MUST be empty, even if Count has increased.</p> + </tp:docstring> + </arg> + <arg name="Mails_Removed" type="as"> + <tp:docstring> + A list of e-mail IDs that are being removed from + <tp:member-ref>UnreadMails</tp:member-ref>. + If the <tt>Supports_Unread_Mails</tt> flag is not set, this list + MUST be empty, even if Count has decreased. + </tp:docstring> + </arg> + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>Emitted when <tp:member-ref>UnreadMails</tp:member-ref> or + <tp:member-ref>UnreadMailCount</tp:member-ref> have changed. It MUST + NOT be emited if <tt>Supports_Unread_Mail_Count</tt> flag is not set + in <tp:member-ref>MailNotificationFlags</tp:member-ref>.</p> + + <p><tt>Mails_Added</tt> and + <tt>Mails_Removed</tt> MUST be empty if the + <tt>Supports_Unread_Mails</tt> flag is not set.</p> + </tp:docstring> + </signal> + + <method name="Subscribe" + tp:name-for-bindings="Subscribe"> + <tp:docstring> + <p>This method subscribes a client to the notification interface. This + MUST be called by clients before using this interface.</p> + + <p>The Connection tracks a subscription count (like a refcount) for + each unique bus name that has called Subscribe(). When a client calls + Unsubscribe(), it releases one "reference". If a client exits + (or crashes), the Connection releases all "references" held on its + behalf.</p> + + <tp:rationale> + <p>The reference count imposed on the subscription simplifies + implementation of client running in the same process + (e.g. plug-ins): two plug-ins interested in mail notification can + call Subscribe and Unsubscribe independently without interfering + with each other.</p> + + <p>This method exists to reduce memory and network overhead when + there is no active subscription. An example of a protocol that + benefits from this method is the Google XMPP Mail Notification + extension: in this protocol, the CM receives a notification + that something has changed, but to get more information, the CM + must request this information. Knowing that nobody is currently + interested in this information, the CM can avoid generating + useless network traffic. Similarly, the CM may free + the list of unread messages to reduce memory overhead.</p> + </tp:rationale> + + </tp:docstring> + <tp:possible-errors> + <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> + <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/> + </tp:possible-errors> + </method> + + <method name="Unsubscribe" + tp:name-for-bindings="Unsubscribe"> + <tp:docstring> + This method unsubscribes a client from the notification interface. + This SHOULD be called by each client that has successfully called + Subscribe when it no longer needs the mail notification interface. + + <tp:rationale> + See <tp:member-ref>Subscribe</tp:member-ref> for rationale. + </tp:rationale> + </tp:docstring> + <tp:possible-errors> + <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"> + <tp:docstring> + Raised if the client calling this method has no references to + release. + </tp:docstring> + </tp:error> + <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/> + </tp:possible-errors> + </method> + + <method name="RequestInboxURL" + tp:name-for-bindings="Request_Inbox_URL"> + <arg direction="out" name="URL" type="(sua(ss))" tp:type="Mail_URL" > + <tp:docstring> + A struture containing a URL and optional additional data to open a + webmail client, without re-authentication if possible. + </tp:docstring> + </arg> + <tp:docstring> + This method creates and returns a URL and an optional POST data that + allow opening the Inbox folder of a webmail account. This URL MAY + contain tokens with a short lifetime, so clients SHOULD request a new + URL for each visit to the webmail interface. This method is implemented + only if the <tt>Supports_Request_Inbox_URL</tt> flag is set in + <tp:member-ref>MailNotificationFlags</tp:member-ref>. + + <tp:rationale> + We are not using properties here because the tokens are unsuitable + for sharing between clients, and network round-trips may be required + to obtain the information that leads to authentication free webmail + access. + </tp:rationale> + </tp:docstring> + <tp:possible-errors> + <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> + <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/> + <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/> + </tp:possible-errors> + </method> + + <method name="RequestMailURL" + tp:name-for-bindings="Request_Mail_URL"> + <arg direction="in" name="ID" type="s"> + <tp:docstring> + The mail's <tt>id</tt> as found in the <tp:type>Mail</tp:type> + structure, or the empty string if no <tt>id</tt> key was provided. + </tp:docstring> + </arg> + <arg direction="in" name="URL_Data" type="v"> + <tp:docstring> + Whatever <tt>url-data</tt> was found in the <tp:type>Mail</tp:type> + structure, or the boolean value False (D-Bus type 'b') if no + <tt>url-data</tt> was provided in the Mail. + </tp:docstring> + </arg> + <arg direction="out" name="URL" type="(sua(ss))" tp:type="Mail_URL" > + <tp:docstring> + A struture that contains a URL and optional additional data to open a + webmail client, without re-authentication if possible. + </tp:docstring> + </arg> + <tp:docstring> + This method creates and returns a URL and optional POST data that + allow opening a specific mail in a webmail interface. This + method is implemented only if <tt>Supports_Request_Mail_URL</tt> flag + is set in <tp:member-ref>MailNotificationFlags</tp:member-ref>. + <tp:rationale> + See <tp:member-ref>RequestInboxURL</tp:member-ref> for design + rationale. + </tp:rationale> + </tp:docstring> + <tp:possible-errors> + <tp:error name="org.freedesktop.Telepathy.Error.Disconnected"/> + <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/> + <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/> + <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/> + </tp:possible-errors> + </method> + + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> + <p>An interface to support receiving notifications about a e-mail + account associated with this connection.</p> + + <p>In protocols where this is possible, this interface also allows the + connection manager to provide the necessary information for clients + to open a web-based mail client without having to re-authenticate.</p> + + <p>To use this interface, a client MUST first subscribe using the + <tp:member-ref>Subscribe</tp:member-ref> method. The subscription + mechanic aims at reducing network traffic and memory footprint in the + situation where nobody is currently interesting in provided + information. When done with this interface, clients SHOULD call + <tp:member-ref>Unsubscribe</tp:member-ref> to release resources in + the CM.</p> + + <p>Protocols have various different levels of Mail Notification support. + To describe the level of support, the interface provides a property + called <tp:member-ref>MailNotificationFlags</tp:member-ref>. + Not all combinations are valid; protocols can be divided into four + categories as follows.</p> + + <p>Connections to the most capable protocols, such as Google's XMPP Mail + Notification extension, have the Supports_Unread_Mails flag (this + implies that they must also have Supports_Unread_Mail_Count, but not + Emits_Mails_Received). On these connections, clients + requiring change notification MUST monitor the + <tp:member-ref>UnreadMailsChanged</tp:member-ref> signal, and + either recover the initial state from the + <tp:member-ref>UnreadMails</tp:member-ref> property (if they require + details other than the number of mails) or the + <tp:member-ref>UnreadMailCount</tp:member-ref> property (if they + are only interested in the number of unread mails). The + <tp:member-ref>MailsReceived</tp:member-ref> signal is never emitted + on these connections, so clients that will display a short-term + notification for each new mail MUST do so in response to emission of + the <tp:member-ref>UnreadMailsChanged</tp:member-ref> signal.</p> + + <p>The most common situation, seen in protocols like MSN and Yahoo, is + that the number of unread mails is provided and kept up-to-date, + and a separate notification is emitted with some details of each new + mail. This is a combination of the following two features, and clients + SHOULD implement one or both as appropriate for their requirements.</p> + + <p>On protocols that have the Emits_Mails_Received flag (which implies + that they do not have Supports_Unread_Mails), the CM does not keep + track of any mails; it simply emits a notification whenever new mail + arrives. Those events may be used for short term display (like a + notification popup) to inform the user. No protocol is known to support + only this feature, but it is useful for integration with libraries that + that do not implement tracking of the number of mails. Clients + requiring these notifications MUST monitor the + <tp:member-ref>MailsReceived</tp:member-ref> signal on any connections + with this flag.</p> + + <p>On protocols that have the Supports_Unread_Mail_Count flag but not + the Supports_Unread_Mails flag, clients cannot display complete + details of unread email, but can display an up-to-date count of the + <em>number</em> of unread mails. To do this, they must monitor the + <tp:member-ref>UnreadMailsChanged</tp:member-ref> signal, and + retrieve the initial state from the + <tp:member-ref>UnreadMailCount</tp:member-ref> property.</p> + + <p> + Orthogonal features described by the + <tp:member-ref>MailNotificationFlags</tp:member-ref> property include the + RequestSomethingURL methods, which are used to obtain URLs allowing + clients to open a webmail client. Connections SHOULD support as many + of these methods as possible.</p> + </tp:docstring> + </interface> +</node> +<!-- vim:set sw=2 sts=2 et ft=xml: --> + diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml index f603971..c4fecd6 100644 --- a/spec/Connection_Manager.xml +++ b/spec/Connection_Manager.xml @@ -72,16 +72,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <li>local-xmpp - Link-local XMPP (XEP-0174) (Bonjour, Salut)</li> <li>msn - MSNP (Windows Live Messenger)</li> <li>myspace - MySpaceIM</li> + <li>mxit - MXit</li> <li>napster - Napster</li> <li>qq - Tencent QQ</li> <li>sametime - IBM Lotus Sametime</li> <li>silc - SILC</li> - <li>sip - Session Initiation Protocol (SIP)</li> + <li>sip - Session Initiation Protocol (SIP), with or without + SIMPLE support</li> <li>skype - Skype</li> <li>tel - telephony (the PSTN, including GSM, CDMA and fixed-line telephony)</li> <li>trepia - Trepia</li> <li>yahoo - YMSG (Yahoo! Messenger)</li> + <li>yahoojp - Japanese version of YMSG</li> <li>zephyr - Zephyr</li> </ul> </tp:docstring> @@ -176,7 +179,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ </tp:docstring> <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"> - The requested protocol is not supported by this manager + <tp:docstring> + The requested protocol is not supported by this manager + </tp:docstring> </tp:error> </tp:possible-errors> </method> @@ -313,6 +318,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ pings.</dd> </dl> + <p>Connection manager authors SHOULD avoid introducing parameters + whose default values would not be serializable in a + <code>.manager</code> file.</p> + + <tp:rationale> + <p>The same serialization format is used in Mission Control + to store accounts.</p> + </tp:rationale> + <p>Every successful RequestConnection call will cause the emission of a <tp:member-ref>NewConnection</tp:member-ref> signal for the same newly created connection. The @@ -324,13 +338,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <tp:possible-errors> <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/> <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"> - The requested protocol is not supported by this manager + <tp:docstring> + The requested protocol is not supported by this manager + </tp:docstring> </tp:error> <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"> - The requested connection already appears to exist + <tp:docstring> + The requested connection already appears to exist + </tp:docstring> </tp:error> <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"> - Unrecognised connection parameters + <tp:docstring> + Unrecognised connection parameters + </tp:docstring> </tp:error> </tp:possible-errors> </method> @@ -451,7 +471,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <dd>The object path as an ASCII string</dd> <dt>b (boolean)</dt> <dd>"true" (case-insensitively) or "1" means True, "false" - (case-insensitively) or "0" means False</dd> + (case-insensitively) or "0" means False; when writing a file, + "true" and "false" SHOULD be used</dd> <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> diff --git a/spec/all.xml b/spec/all.xml index 84adf0b..0ec4708 100644 --- a/spec/all.xml +++ b/spec/all.xml @@ -3,10 +3,10 @@ xmlns:xi="http://www.w3.org/2001/XInclude"> <tp:title>Telepathy D-Bus Interface Specification</tp:title> -<tp:version>0.19.0</tp:version> +<tp:version>0.19.3</tp:version> -<tp:copyright>Copyright © 2005-2009 Collabora Limited</tp:copyright> -<tp:copyright>Copyright © 2005-2009 Nokia Corporation</tp:copyright> +<tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright> +<tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright> <tp:copyright>Copyright © 2006 INdT</tp:copyright> <tp:license xmlns="http://www.w3.org/1999/xhtml"> @@ -49,6 +49,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <xi:include href="Connection_Interface_Contact_Info.xml"/> <xi:include href="Connection_Interface_Contacts.xml"/> <xi:include href="Connection_Interface_Location.xml"/> + <xi:include href="Connection_Interface_Mail_Notification.xml"/> <xi:include href="Connection_Interface_Presence.xml"/> <xi:include href="Connection_Interface_Renaming.xml"/> <xi:include href="Connection_Interface_Requests.xml"/> @@ -188,8 +189,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</ <xi:include href="Connection_Interface_Forwarding.xml"/> --> <!-- Never implemented, vague <xi:include href="Connection_Interface_Privacy.xml"/> --> -<!-- Never implemented, can't be implemented with current dbus-glib, vague -<xi:include href="Channel_Type_Contact_Search.xml"/> --> <!-- Causes havoc, never implemented, unclear requirements <xi:include href="Channel_Interface_Transfer.xml"/> --> |