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 Street, Fifth Floor, Boston, MA 02110-1301, USA.
org.freedesktop.Telepathy.ConnectionManager
org.freedesktop.Telepathy.Connection
org.freedesktop.Telepathy.Connection.Interface.Aliasing
org.freedesktop.Telepathy.Connection.Interface.Avatars
org.freedesktop.Telepathy.Connection.Interface.Capabilities
org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT
org.freedesktop.Telepathy.Connection.Interface.ContactInfo.DRAFT
org.freedesktop.Telepathy.Connection.Interface.Contacts
org.freedesktop.Telepathy.Connection.Interface.Location.DRAFT
org.freedesktop.Telepathy.Connection.Interface.Presence
org.freedesktop.Telepathy.Connection.Interface.Renaming
org.freedesktop.Telepathy.Connection.Interface.Requests
org.freedesktop.Telepathy.Connection.Interface.SimplePresence
org.freedesktop.Telepathy.ChannelBundle.DRAFT
org.freedesktop.Telepathy.Channel
org.freedesktop.Telepathy.Channel.FUTURE
org.freedesktop.Telepathy.Channel.Type.ContactList
org.freedesktop.Telepathy.Channel.Type.StreamedMedia
org.freedesktop.Telepathy.Channel.Type.StreamedMedia.FUTURE
org.freedesktop.Telepathy.Channel.Type.RoomList
org.freedesktop.Telepathy.Channel.Type.Text
org.freedesktop.Telepathy.Channel.Type.Tubes
org.freedesktop.Telepathy.Channel.Type.StreamTube.DRAFT
org.freedesktop.Telepathy.Channel.Type.DBusTube.DRAFT
org.freedesktop.Telepathy.Channel.Type.FileTransfer
org.freedesktop.Telepathy.Channel.Interface.CallMerging
org.freedesktop.Telepathy.Channel.Interface.CallState
org.freedesktop.Telepathy.Channel.Interface.ChatState
org.freedesktop.Telepathy.Channel.Interface.Destroyable
org.freedesktop.Telepathy.Channel.Interface.DTMF
org.freedesktop.Telepathy.Channel.Interface.Group
org.freedesktop.Telepathy.Channel.Interface.Hold
org.freedesktop.Telepathy.Channel.Interface.HTML.DRAFT
org.freedesktop.Telepathy.Channel.Interface.Password
org.freedesktop.Telepathy.Channel.Interface.MediaSignalling
org.freedesktop.Telepathy.Channel.Interface.MediaSignalling.FUTURE
org.freedesktop.Telepathy.Channel.Interface.Messages
org.freedesktop.Telepathy.Channel.Interface.Tube.DRAFT
org.freedesktop.Telepathy.Media.SessionHandler
org.freedesktop.Telepathy.Media.StreamHandler
org.freedesktop.Telepathy.Properties
org.freedesktop.Telepathy.AccountManager
org.freedesktop.Telepathy.Account
org.freedesktop.Telepathy.Account.Interface.Avatar
org.freedesktop.Telepathy.ChannelDispatcher.DRAFT
org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList.DRAFT
org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT
org.freedesktop.Telepathy.ChannelRequest.DRAFT
org.freedesktop.Telepathy.Client.DRAFT
org.freedesktop.Telepathy.Client.Observer.DRAFT
org.freedesktop.Telepathy.Client.Approver.DRAFT
org.freedesktop.Telepathy.Client.Handler.DRAFT
org.freedesktop.Telepathy.ChannelHandler
A D-Bus service which allows connections to be created. The manager processes are intended to be started by D-Bus service activation.
For service discovery, each Telepathy connection manager must have a connection manager name (see Connection_Manager_Name for syntax).
The connection manager must then provide a well-known bus name of
org.freedesktop.Telepathy.ConnectionManager.cmname
where cmname is its connection manager name. If it makes sense
to start the connection manager using D-Bus service activation, it
must register that well-known name for service activation by installing
a .service file.
Clients can list the running connection managers by calling the ListNames method on the D-Bus daemon's org.freedesktop.DBus interface and looking for names matching the above pattern; they can list the activatable connection managers by calling ListActivatableNames, and they should usually combine the two lists to get a complete list of running or activatable connection managers.
When the connection manager is running, it must have an object
implementing the ConnectionManager interface at the object path
/org/freedesktop/Telepathy/ConnectionManager/cmname
.
Connection managers' capabilities can be determined dynamically by calling their ListProtocols method, then for each protocol of interest, calling GetParameters to discover the required and optional parameters. However, since it is inefficient to activate all possible connection managers on the system just to find out what they can do, there is a standard mechanism to store static information about CMs in ".manager files".
To look up a connection manager's supported protocols, clients
should search the data directories specified by
the
freedesktop.org XDG Base Directory Specification ($XDG_DATA_HOME,
defaulting to $HOME/.local/share if unset, followed by
colon-separated paths from $XDG_DATA_DIRS, defaulting to
/usr/local/share:/usr/share if unset) for the first file named
telepathy/managers/cmname.manager
that can be
read without error. This file has the same syntax as a
freedesktop.org Desktop Entry file.
Clients must still support connection managers for which no
.manager
file can be found, which they can do by activating
the connection manager and calling its methods; the
.manager
file is merely an optimization. Connection managers
whose list of protocols can change at any time (for instance, via
a plugin architecture) should not install a .manager
file.
For each protocol name proto that would be returned by
ListProtocols, the .manager file contains a group
headed [Protocol proto]
. For each parameter
p that would be returned by GetParameters(proto), the
.manager file contains a key param-p
with a value
consisting of a D-Bus signature (a single complete type), optionally
followed by a space and a space-separated list of flags. The supported
flags are:
required
, corresponding to
Conn_Mgr_Param_Flag_Requiredregister
, corresponding
to Conn_Mgr_Param_Flag_Registersecret
, corresponding
to Conn_Mgr_Param_Flag_Secretdbus-property
, corresponding
to Conn_Mgr_Param_Flag_DBus_PropertyThe group may also contain a key default-p
whose value is a string form of the default value for the parameter.
If this key exists, it sets the default, and also sets the flag
Conn_Mgr_Param_Flag_Has_Default. The default value is formatted
according to the D-Bus signature as follows:
Currently, no other D-Bus signatures are allowed to have default values,
but clients parsing the .manager file MUST ignore defaults
that they cannot parse, and treat them as if the
default-p
key was not present at all.
It is not required that a connection manager be able to support multiple protocols, or even multiple connections. When a connection is made, a service name where the connection object can be found is returned. A manager which can only make one connection may then remove itself from its well-known bus name, causing a new connection manager to be activated when somebody attempts to make a new connection.
Changed in version 0.17.2: Prior to version 0.17.2, support for CMs with no .manager file was not explicitly required.
Changed in version 0.17.16: Prior to version 0.17.16 the serialization of string arrays (signature 'as') was not defined
Protocol
−
s
(Protocol)Parameters
−
a(susv)
(Param_Spec[])org.freedesktop.Telepathy.Error.NotImplemented
Protocols
−
as
(Protocol[])Request a Connection object representing a given account on a given protocol with the given parameters. The method returns the bus name and the object path where the new Connection object can be found, which should have the status of Connection_Status_Disconnected, to allow signal handlers to be attached before connecting is started with the Connect method.
The parameters which must and may be provided in the parameters dictionary can be discovered with the GetParameters method. These parameters, their types, and their default values may be cached in files so that all available connection managers do not need to be started to discover which protocols are available.
To request values for these parameters from the user, a client must have prior knowledge of the meaning of the parameter names, so the following well-known names and types should be used where appropriate:
Every successful RequestConnection call will cause the emission of a NewConnection signal for the same newly created connection. The requester can use the returned object path and service name independently of the emission of that signal. In that case this signal emission is most useful for, e.g. other processes that are monitoring the creation of new connections.
Protocol
−
s
(Protocol)Parameters
−
a{sv}
(String_Variant_Map)Bus_Name
−
s
(DBus_Bus_Name)Object_Path
−
o
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidArgument
Bus_Name
−
s
(DBus_Bus_Name)Object_Path
−
o
Protocol
−
s
(Protocol)Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
, read-onlyA list of the extra interfaces provided by this connection manager (i.e. extra functionality that can be provided even before a connection has been created).
No interfaces suitable for listing in this property are currently defined; it's provided as a hook for possible future functionality.
To be compatible with older connection managers, if retrieving this property fails, clients SHOULD assume that its value is an empty list.
Added in version 0.17.8.
The name of a connection manager, found in its well-known bus name and object path. This must be a non-empty string of ASCII letters, digits and underscores, starting with a letter. This is typically the name of the executable with any "telepathy-" prefix removed, and any hyphen/minus signs replaced by underscores.
Connection manager names SHOULD NOT be the same as the name of the protocol they implement.
This is likely to lead to conflicts between different implementations of the same protocol (or indeed inability to distinguish between the different implementations!). The Telepathy project traditionally uses some sort of pun (Haze is based on libpurple, Salut implements a protocol often called Bonjour, and Wilde implements the OSCAR protocol).
Connection manager names SHOULD NOT be the same as the name of a library on which they are based.
We often abbreviate, for instance, telepathy-haze as "Haze", but abbreviating telepathy-sofiasip to "Sofia-SIP" would cause confusion between the connection manager and the library it uses. Please don't repeat that mistake.
Changed in version 0.17.1: Prior to version 0.17.1, the allowed characters were not specified
An instant messaging protocol. It must consist only of ASCII letters, digits and hyphen/minus signs (U+002D "-"), and must start with a letter. Where possible, this SHOULD be chosen from the following well-known values:
Changed in version 0.17.1: Prior to version 0.17.1, the allowed characters were not specified
Conn_Mgr_Param_Flag_Required = 1
Conn_Mgr_Param_Flag_Register = 2
Conn_Mgr_Param_Flag_Has_Default = 4
Conn_Mgr_Param_Flag_Secret = 8
This parameter should be considered private or secret; for instance, clients should store it in a "password safe" like gnome-keyring or kwallet, omit it from debug logs, and use a text input widget that hides the value of the parameter.
(Clients that support older connection managers may also treat any parameter whose name contains "password" as though it had this flag.)
Added in version 0.17.2.
Conn_Mgr_Param_Flag_DBus_Property = 16
com.example.Duck.Macaroni
with this flag
corresponds to the Macaroni
property on the
com.example.Duck
interface. Its value can be queried
and possibly changed on an existing Connection using methods on the
org.freedesktop.DBus.Properties
interface.
Added in version 0.17.16.
In bindings that need a separate name, arrays of Param_Spec should be called Param_Spec_List.
Name
−
s
Flags
−
u
(Conn_Mgr_Param_Flags)Signature
−
s
(DBus_Signature)Default_Value
−
v
This models a connection to a single user account on a communication service. Its basic capability is to provide the facility to request and receive channels of differing types (such as text channels or streaming media channels) which are used to carry out further communication.
In order to allow Connection objects to be discovered by new clients,
the object path and well-known bus name MUST be of the form
/org/freedesktop/Telepathy/Connection/cmname/proto/account
and
org.freedesktop.Telepathy.Connection.cmname.proto.account
where:
account SHOULD be formed such that any valid distinct connection instance on this protocol has a distinct name. This might be formed by including the server name followed by the user name (escaped via some suitable mechanism like telepathy-glib's tp_escape_as_identifier() function to preserve uniqueness); on protocols where connecting multiple times is permissable, a per-connection identifier might be necessary to ensure uniqueness.
Clients MAY parse the object path to determine the connection manager name and the protocol, but MUST NOT attempt to parse the account part. Connection managers MAY use any unique string for this part.
As well as the methods and signatures below, arbitrary interfaces may be provided by the Connection object to represent extra connection-wide functionality, such as the Connection.Interface.Presence for receiving and reporting presence information, and Connection.Interface.Aliasing for connections where contacts may set and change an alias for themselves. These interfaces can be discovered using the GetInterfaces method.
Contacts, rooms, and server-stored lists (such as subscribed contacts, block lists, or allow lists) on a service are all represented by immutable handles, which are unsigned non-zero integers which are valid only for the lifetime of the connection object, and are used throughout the protocol where these entities are represented, allowing simple testing of equality within clients.
Zero as a handle value is sometimes used as a "null" value to mean the absence of a contact, room, etc.
Handles have per-type uniqueness, meaning that every (handle type, handle number) tuple is guaranteed to be unique within a connection and that a handle alone (without its type) is meaningless or ambiguous. Connection manager implementations should reference count these handles to determine if they are in use either by any active clients or any open channels, and may deallocate them when this ceases to be true. Clients may request handles of a given type and name with the RequestHandles method, inspect the entity name of handles with the InspectHandles method, keep handles from being released with HoldHandles, and notify that they are no longer storing handles with ReleaseHandles.
Changed in version 0.17.10: Previously, the account part of Connection bus names/object paths was allowed to have more than one component (i.e. contain dots or slashes), resulting in Connection bus names and object paths with more than 7 components. We now restrict Connection bus names/object paths to have exactly 7 components.
org.freedesktop.Telepathy.Error.NotAvailable
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 interfaces will only be added, not removed. After the connection status changes to CONNECTED, the return from this method cannot change further.
There is no explicit change notification; reasonable behaviour for a client would be to retrieve the interfaces list once initially, and once more when it becomes CONNECTED.
In some connection managers, certain capabilities of a connection are known to be implemented for all connections (e.g. support for SimplePresence), and some interfaces (like SimplePresence) can even be used before connecting. Other capabilities may or may not exist, depending on server functionality; by the time the connection goes CONNECTED, the connection manager is expected to have evaluated the server's functionality and enabled any extra interfaces for the remainder of the Connection's lifetime.
Interfaces
−
as
(DBus_Interface[])org.freedesktop.Telepathy.Error.Disconnected
Protocol
−
s
(Protocol)Deprecated since version 0.17.10. Use GetAll to get the SelfHandle property (and all other Connection properties) instead.
Self_Handle
−
u
(Contact_Handle)org.freedesktop.Telepathy.Error.Disconnected
Status
−
u
(Connection_Status)Notify the connection manger that your client is holding a copy of handles which may not be in use in any existing channel or list, and were not obtained by using the RequestHandles method. For example, a handle observed in an emitted signal, or displayed somewhere in the UI that is not associated with a channel. The connection manager must not deallocate a handle where any clients have used this method to indicate it is in use until the ReleaseHandles method is called, or the clients disappear from the bus.
Note that HoldHandles is idempotent - calling it multiple times is equivalent to calling it once. If a handle is "referenced" by several components which share a D-Bus unique name, the client should perform reference counting internally, and only call ReleaseHandles when none of the cooperating components need the handle any longer.
Handle_Type
−
u
(Handle_Type)Handles
−
au
(Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.InvalidHandle
Handle_Type
−
u
(Handle_Type)Handles
−
au
(Handle[])Identifiers
−
as
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.InvalidHandle
Channel_Info
−
a(osuu)
(Channel_Info[])org.freedesktop.Telepathy.Error.Disconnected
Handle_Type
−
u
(Handle_Type)Handles
−
au
(Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NotAvailable
Request a channel satisfying the specified type and communicating with the contact, room, list etc. indicated by the given handle_type and handle. The handle_type and handle may both be zero to request the creation of a new, empty channel, which may or may not be possible, depending on the protocol and channel type.
On success, the returned channel will always be of the requested type (i.e. implement the requested channel-type interface).
If a new, empty channel is requested, on success the returned channel will always be an "anonymous" channel for which the type and handle are both zero.
If a channel to a contact, room etc. is requested, on success, the returned channel may either be a new or existing channel to the requested entity (i.e. its TargetHandleType and TargetHandle properties are the requested handle type and handle), or a newly created "anonymous" channel associated with the requested handle in some implementation-specific way.
For example, for a contact handle, the returned channel might be "anonymous", but implement the groups interface and have the requested contact already present among the members.
If the request cannot be satisfied, an error is raised and no channel is created.
Type
−
s
(DBus_Interface)Handle_Type
−
u
(Handle_Type)Handle
−
u
(Handle)Suppress_Handler
−
b
Object_Path
−
o
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotCapable
org.freedesktop.Telepathy.Error.Channel.Banned
org.freedesktop.Telepathy.Error.Channel.Full
org.freedesktop.Telepathy.Error.Channel.InviteOnly
Handle_Type
−
u
(Handle_Type)Names
−
as
Handles
−
au
(Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NotImplemented
Added in version 0.17.10. Clients MAY assume that if the SelfHandle property exists, this signal will be emitted when necessary.
Self_Handle
−
u
(Contact_Handle)Object_Path
−
o
Channel_Type
−
s
(DBus_Interface)Handle_Type
−
u
(Handle_Type)Handle
−
u
(Handle)Suppress_Handler
−
b
If true, the channel was requested by a client that intends to present it to the user itself (i.e. it passed suppress_handler=TRUE to the RequestChannel method), so no other handler should be launched. Clients MAY assume that channels where this is true were created by a user request.
If false, either the channel was created due to incoming information from the service, or the channel was requested by a local client that does not intend to handle the channel itself (this usage is deprecated).
Clients MUST NOT assume that only incoming channels will have this flag set to false.
Emitted when an error occurs that renders this connection unusable.
Whenever this signal is emitted, it MUST immediately be followed by a StatusChanged signal with status Connection_Status_Reason_Disconnected and an appropriate reason code.
Connection managers SHOULD emit this signal on disconnection, but need not do so. Clients MUST support connection managers that emit StatusChanged(Disconnected, ...) without first emitting ConnectionError.
This signal provides additional information about the reason for disconnection. The reason for connection is always straightforward - it was requested - so it does not need further explanation. However, on errors, it can be useful to provide additional information.
The Connection_Status_Reason is not given here, since it will be signalled in StatusChanged. A reasonable client implementation would be to store the information given by this signal until StatusChanged is received, at which point the information given by this signal can be used to supplement the StatusChanged signal.
Error
−
s
(DBus_Error_Name)Details
−
a{sv}
(String_Variant_Map)Additional information about the error, which may include the following well-known keys:
This argument allows for future extensions. For instance, if indicating DNS lookup failure, we could define a key that indicates the hostname that could not be found.
Status
−
u
(Connection_Status)Reason
−
u
(Connection_Status_Reason)Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
SelfHandle
− u
(Contact_Handle), read-onlyAdded in version 0.17.10. For compatibility with older versions, clients should fall back to calling the GetSelfHandle method.
Handle_Type_None = 0
Handle_Type_Contact = 1
Handle_Type_Room = 2
Handle_Type_List = 3
Handle_Type_Group = 4
Connection_Status_Connected = 0
Connection_Status_Connecting = 1
Connection_Status_Disconnected = 2
A reason why the status of the connection changed. Apart from Requested, the values of this enumeration only make sense as reasons why the status changed to Disconnected.
Connection_Status_Reason_None_Specified = 0
There is no reason set for this state change. Unknown status reasons SHOULD be treated like this reason.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Disconnected
.
Connection_Status_Reason_Requested = 1
The change is in response to a user request. Changes to the Connecting or Connected status SHOULD always indicate this reason; changes to the Disconnected status SHOULD indicate this reason if and only if the disconnection was requested by the user.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cancelled
.
Connection_Status_Reason_Network_Error = 2
There was an error sending or receiving on the network socket.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.NetworkError
.
Connection_Status_Reason_Authentication_Failed = 3
The username or password was invalid.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.AuthenticationFailed
.
Connection_Status_Reason_Encryption_Error = 4
There was an error negotiating SSL on this connection, or encryption was unavailable and require-encryption was set when the connection was created.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.EncryptionNotAvailable
if encryption was not available at all, or
org.freedesktop.Telepathy.Error.EncryptionError
if encryption failed.
Connection_Status_Reason_Name_In_Use = 5
In general, this reason indicates that the requested account name or other identification could not be used due to conflict with another connection. It can be divided into three cases:
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.NotYours
.
Connection_Status_Reason_Cert_Not_Provided = 6
The server did not provide a SSL certificate.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.NotProvided
.
Connection_Status_Reason_Cert_Untrusted = 7
The server's SSL certificate is signed by an untrusted certifying authority. This error SHOULD NOT be used to represent a self-signed certificate: use the more specific Cert_Self_Signed reason for that.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.Untrusted
.
Connection_Status_Reason_Cert_Expired = 8
The server's SSL certificate has expired.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.Expired
.
Connection_Status_Reason_Cert_Not_Activated = 9
The server's SSL certificate is not yet valid.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.NotActivated
.
Connection_Status_Reason_Cert_Hostname_Mismatch = 10
The server's SSL certificate did not match its hostname.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.HostnameMismatch
.
Connection_Status_Reason_Cert_Fingerprint_Mismatch = 11
The server's SSL certificate does not have the expected fingerprint.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.FingerprintMismatch
.
Connection_Status_Reason_Cert_Self_Signed = 12
The server's SSL certificate is self-signed.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.HostnameMismatch
.
Connection_Status_Reason_Cert_Other_Error = 13
There was some other error validating the server's SSL certificate.
When disconnected for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Cert.Invalid
.
In bindings that need a separate name, arrays of Channel_Info should be called Channel_Info_List.
Channel
−
o
Channel_Type
−
s
(DBus_Interface)Handle_Type
−
u
(Handle_Type)Handle
−
u
(Handle)Implementations of this interface must also implement:
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 their own alias, and a signal which should be emitted when a contact's alias is changed or first discovered.
On connections where the user is allowed to set aliases for contacts and store them on the server, the GetAliasFlags method will have the CONNECTION_ALIAS_FLAG_USER_SET flag set, and the SetAliases method may be called on contact handles other than the user themselves.
Aliases are intended to be used as the main displayed name for the contact, where available.
Alias_Flags
−
u
(Connection_Alias_Flags)org.freedesktop.Telepathy.Error.Disconnected
Contacts
−
au
(Contact_Handle[])Aliases
−
as
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidHandle
Contacts
−
au
(Contact_Handle[])Aliases
−
a{us}
(Alias_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
Aliases
−
a{us}
(Alias_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
Aliases
−
a(us)
(Alias_Pair[])Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Connection_Alias_Flag_User_Set = 1
The aliases of contacts on this connection may be changed by the user of the service, not just by the contacts themselves. This is the case on Jabber, for instance.
It is possible that aliases can be changed by the contacts too - which alias takes precedence is not defined by this specification, and depends on the server and/or connection manager implementation.
This flag only applies to the aliases of "globally valid" contact handles. At this time, clients should not expect to be able to change the aliases corresponding to any channel-specific handles. If this becomes possible in future, a new flag will be defined.
In bindings that need a separate name, arrays of Alias_Pair should be called Alias_Pair_List.
Handle
−
u
(Contact_Handle)Alias
−
s
Handle
−
u
(Contact_Handle)Alias
−
s
Implementations of this interface must also implement:
An interface for requesting avatars for contacts on a given connection, receiving notification when avatars are changed, and publishing your own avatar.
Avatars are identified by a string, the Avatar_Token, which represents a particular avatar. Tokens MUST be chosen by the connection manager in such a way that the triple (Connection_Manager_Name, Protocol, Avatar_Token) uniquely identifies an avatar. An empty token means that an avatar has not been set for this contact, and a changed token implies the contact's avatar has changed, but the strings should otherwise be considered opaque by clients.
A client should use GetKnownAvatarTokens to request the tokens for the avatars of all the contacts it is interested in when it connects. The avatars can then be requested using RequestAvatars for the contacts. Clients should bind to the AvatarUpdated signal and request a new copy of the avatar when a contacts' avatar token changes. Clients should cache the token and data of each contact's avatar between connections, to avoid repeatedly retrieving the same avatar.
To publish an avatar, a client should use SetAvatar to provide an image which meets the requirements returned by the GetAvatarRequirements function. On some protocols the avatar is stored on the server, so setting the avatar is persistent, but on others it is transferred via a peer to peer mechanism, so needs to be set every connection. Hence, on every connection, clients should inspect the avatar token of the connection's self handle using GetKnownAvatarTokens; if the self handle is not in the returned map, the client should re-set the avatar. If the self handle's avatar token is known, but the avatar has been changed locally since the last connection, the client should upload the new avatar; if the avatar has not changed locally, then the client should download the avatar from the server if its token differs from the that of the local avatar.
To remove the published avatar on protocols which have persistent avatars, a client should use the ClearAvatar method. This method can safely be used even if there is no avatar for this connection.
MIME_Types
−
as
Min_Width
−
q
Min_Height
−
q
Max_Width
−
q
Max_Height
−
q
Max_Bytes
−
u
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
Contacts
−
au
(Contact_Handle[])Tokens
−
as
(Avatar_Token[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
Contacts
−
au
(Contact_Handle[])Tokens
−
a{us}
(Avatar_Token_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
Contact
−
u
(Contact_Handle)Data
−
ay
MIME_Type
−
s
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
Contacts
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
Avatar
−
ay
MIME_Type
−
s
Token
−
s
(Avatar_Token)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
Added in version 0.15.0.
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Contact
−
u
(Contact_Handle)New_Avatar_Token
−
s
(Avatar_Token)Contact
−
u
(Contact_Handle)Token
−
s
(Avatar_Token)Avatar
−
ay
Type
−
s
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
An opaque token chosen by the connection manager, representing a particular avatar.
Because avatars can be relatively large images, most protocols provide a way to detect whether an old avatar is still valid, or whether an avatar has changed, without pushing the actual avatar data to all clients.
The connection manager MUST choose these tokens in a way that makes it highly unlikely that two different avatars with the same connection manager and protocol will have the same token.
This means that clients MAY use the triple (Connection_Manager_Name, Protocol, avatar token) as a key for their avatar cache. For instance, an avatar for a telepathy-gabble Jabber contact might be stored in a file .../gabble/jabber/4e199b4a1c40b497a95fcd1cd896351733849949.png.
For instance, some protocols (like XMPP) identify avatars by a hash of the avatar data; in this case, the hash can be used as the avatar token.
Some protocols identify avatars by the timestamp of the last change to the avatar; in these protocols it would be necessary for the connection manager to encode both the timestamp and the contact's identifier into the avatar token in order to ensure uniqueness.
This token SHOULD be kept short and reasonably suitable for use in a filename, but MAY contain any UTF-8 character (so clients using avatar tokens in filenames MUST be prepared to escape characters that are not valid in filenames). Connection managers for protocols where tokens would otherwise become inconveniently large or contain many unsuitable characters SHOULD hash the identifying data to generate the token.
Changed in version 0.17.16: strengthened uniqueness requirements so (CM name, protocol, token) is unique; previously only (our Account, remote contact identifier, token) was required to be unique
Handle
−
u
(Contact_Handle)Token
−
s
(Avatar_Token)Implementations of this interface must also implement:
An interface for connections where it is possible to know what channel types may be requested before the request is made to the connection object. Each capability represents a commitment by the connection manager that it will ordinarily be able to create a channel when given a request with the given type and handle.
Capabilities pertain to particular contact handles, and represent activities such as having a text chat or a voice call with the user. The activities are represented by the D-Bus interface name of the channel type for that activity.
The generic capability flags are defined by Connection_Capability_Flags.
In addition, channel types may have type specific capability flags of their own, which are described in the documentation for each channel type.
This interface also provides for user interfaces notifying the connection manager of what capabilities to advertise for the user. This is done by using the AdvertiseCapabilities method, and deals with the interface names of channel types and the type specific flags pertaining to them which are implemented by available client processes.
Changed in version 0.17.8: Previously, this interface also expressed capabilities of the connection itself, indicating what sorts of channels could be requested (for instance, the ability to open chatroom lists or chatrooms). However, this was never very well-defined or consistent, and as far as we know it was never implemented correctly. This usage is now deprecated.
Used by user interfaces to indicate which channel types they are able to handle on this connection. Because these may be provided by different client processes, this method accepts channel types to add and remove from the set already advertised on this connection. The type of advertised capabilities (create versus invite) is protocol-dependent and hence cannot be set by the this method. In the case of a client adding an already advertised channel type but with new channel type specific flags, the connection manager should simply add the new flags to the set of advertised capabilities.
Upon a successful invocation of this method, the CapabilitiesChanged signal will be emitted for the user's own handle ( Connection.GetSelfHandle) by the connection manager to indicate the changes that have been made. This signal should also be monitored to ensure 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.
Add
−
a(su)
(Capability_Pair[])Remove
−
as
(DBus_Interface[])Self_Capabilities
−
a(su)
(Capability_Pair[])org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.Disconnected
Handles
−
au
(Contact_Handle[])An array of contact handles for this connection.
This may include zero, which originally meant a query for capabilities available on the connection itself. This usage is deprecated; clients SHOULD NOT do this, and connection managers SHOULD proceed as though zero had not been present in this list.
Contact_Capabilities
−
a(usuu)
(Contact_Capability[])org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.PermissionDenied
Announce that there has been a change of capabilities on the given handle.
If the handle is zero, the capabilities refer to the connection itself, in some poorly defined way. This usage is deprecated and clients should ignore it.
Caps
−
a(usuuuu)
(Capability_Change[])Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Connection_Capability_Flag_Create = 1
Connection_Capability_Flag_Invite = 2
In bindings that need a separate name, arrays of Capability_Pair should be called Capability_Pair_List.
Channel_Type
−
s
(DBus_Interface)Type_Specific_Flags
−
u
In bindings that need a separate name, arrays of Contact_Capability should be called Contact_Capability_List.
Handle
−
u
(Contact_Handle)Channel_Type
−
s
(DBus_Interface)Generic_Flags
−
u
(Connection_Capability_Flags)Type_Specific_Flags
−
u
In bindings that need a separate name, arrays of Capability_Change should be called Capability_Change_List.
Handle
−
u
(Contact_Handle)Channel_Type
−
s
(DBus_Interface)Old_Generic_Flags
−
u
(Connection_Capability_Flags)New_Generic_Flags
−
u
(Connection_Capability_Flags)Old_Type_Specific_Flags
−
u
New_Type_Specific_Flags
−
u
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Contact capabilities describe the channel classes which may be created with a given contact in advance of attempting to create a channel. Each capability represents a commitment by the connection manager that it will ordinarily be able to create a channel with a contact when given a request with the properties defined by the channel class.
Capabilities pertain to particular contact handles, and represent activities such as having a text chat, a voice call with the user or a stream tube of a defined type.
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 SetSelfCapabilities method, and deals with channel property values pertaining to them which are implemented by available client processes.
Added in version 0.17.16. (as a draft)
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.
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.
Upon a successful invocation of this method, the ContactCapabilitiesChanged 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.
The connection manager will essentially intersect the provided capabilities and the channel classes it implements. Therefore, certain properties which are never fixed for a channel class (such as the target handle, or the Parameters property of a tube channel) will almost certainly not be advertised.
caps
−
aa{sv}
(String_Variant_Map[])org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.Disconnected
handles
−
au
(Contact_Handle[])An array of contact handles for this connection.
The handle zero MUST NOT be included in the request.
Contact_Capabilities
−
a{ua(a{sv}as)}
(Contact_Capabilities_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
Announce that there has been a change of capabilities on the given handles. A single signal can be emitted for several contacts.
The underlying protocol can get several contacts' capabilities at the same time.
caps
−
a{ua(a{sv}as)}
(Contact_Capabilities_Map)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
In bindings that need a separate name, arrays of Contact_Capabilities_Map should be called Contact_Capabilities_Map_List.
Key
−
u
(Contact_Handle)Value
−
a(a{sv}as)
(Requestable_Channel_Class[])This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
An interface for requesting information about a contact on a given connection. Information is represented as a list of Contact_Info_Fields forming a structured representation of a vCard (as defined by RFC 2426), using field names and semantics defined therein.
Added in version 0.17.18. (as a draft)
Contacts
−
au
(Contact_Handle[])ContactInfo
−
a{ua(sasas)}
(Contact_Info_Map)Contact
−
u
(Contact_Handle)Contact_Info
−
a(sasas)
(Contact_Info_Field[])org.freedesktop.Telepathy.Error.NotAvailable
ContactInfo
−
a(sasas)
(Contact_Info_Field[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.InvalidArgument
Contact
−
u
(Contact_Handle)ContactInfo
−
a(sasas)
(Contact_Info_Field[])Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ContactInfoFlags
− u
(Contact_Info_Flag), read-onlySupportedFields
− a(sasuu)
(Field_Spec[]), read-onlyA list of field specifications describing the kinds of fields which may be passed to SetContactInfo. The empty list indicates that arbitrary vCard fields are permitted. This property SHOULD be the empty list, and be ignored by clients, if ContactInfoFlags does not contain the Can_Set Contact_Info_Flag.
For example, an implementation of XEP-0054, which defines a mapping of vCards to XML for use over XMPP, would set this property to the empty list. A protocol whose notion of contact information is one each of personal phone number, mobile phone number, location, email address and date of birth, with no attributes allowed on each piece of information, would set this property to (in Python-like syntax):
[ ('tel', ['home'], Parameters_Mandatory, 1), ('tel', ['cell'], Parameters_Mandatory, 1), ('adr', [], Parameters_Mandatory, 1), ('bday', [], Parameters_Mandatory, 1), ('email', ['internet'], Parameters_Mandatory, 1), ]
A protocol which allows users to specify up to four phone numbers,
which may be labelled as personal and/or mobile, would set this
property to [ ('tel', ['home', 'cell'], 0, 4), ]
.
Studying existing IM protocols shows that in practice protocols allow either a very restricted set of fields (such as MSN, which seems to correspond roughly to the largest example above) or something mapping 1-1 to vCard (such as XMPP).
Contact_Info_Flag_Can_Set = 1
Contact_Info_Flag_Push = 2
Contact_Info_Field_Flag_Parameters_Mandatory = 1
If present, exactly the parameters indicated must be set on this field; in the case of an empty list of parameters, this implies that parameters may not be used.
If absent, and the list of allowed parameters is non-empty, any (possibly empty) subset of that list may be used.
If absent, and the list of allowed parameters is empty, any parameters may be used.
Represents one piece of information about a contact, as modelled by a single vCard field. Of the fields defined in RFC 2426, common examples include:
For example, the following vCard:
BEGIN:vCard VERSION:3.0 FN:Wee Ninja N:Ninja;Wee;;;-san ORG:Collabora, Ltd.;Human Resources\; Company Policy Enforcement ADR;TYPE=WORK,POSTAL,PARCEL:;;11 Kings Parade;Cambridge;Cambridgeshire ;CB2 1SJ;UK TEL;TYPE=VOICE,WORK:+44 1223 362967, +44 7700 900753 EMAIL;TYPE=INTERNET,PREF:wee.ninja@collabora.co.uk EMAIL;TYPE=INTERNET:wee.ninja@example.com URL:http://www.thinkgeek.com/geektoys/plush/8823/ END:vCard
would be represented by (in Python-like syntax):
[ ('fn', [], ['Wee Ninja']), ('n', [], ['Ninja', 'Wee', '', '', '-san']), ('org', [], ['Collabora, Ltd.', 'Human Resources; Company Policy Enforcement']), ('adr', ['work','postal','parcel'], ['','','11 Kings Parade','Cambridge', 'Cambridgeshire','CB2 1SJ','UK']), ('tel', ['voice','work'], ['+44 1223 362967']), ('tel', ['voice','work'], ['+44 7700 900753']), ('email', ['internet','pref'], ['wee.ninja@collabora.co.uk']), ('email', ['internet'], ['wee.ninja@example.com']), ('url', [], ['http://www.thinkgeek.com/geektoys/plush/8823/']), ]
In bindings that need a separate name, arrays of Contact_Info_Field should be called Contact_Info_Field_List.
Field_Name
−
s
Parameters
−
as
Field_Value
−
as
In bindings that need a separate name, arrays of Field_Spec should be called Field_Specs.
Name
−
s
Parameters
−
as
Flags
−
u
(Contact_Info_Field_Flags)Max
−
u
Handle
−
u
(Contact_Handle)Contact_Info
−
a(sasas)
(Contact_Info_Field[])Implementations of this interface must also implement:
This interface allows many attributes of many contacts to be obtained in a single D-Bus round trip.
Each contact attribute has an string identifier (Contact_Attribute), which is namespaced by the D-Bus interface which defines it.
An initial set of contact attributes is defined here:
Added in version 0.17.9.
Handles
−
au
(Contact_Handle[])Interfaces
−
as
(DBus_Interface[])A list of strings indicating which D-Bus interfaces the calling process is interested in. All supported attributes from these interfaces, whose values can be obtained without additional network activity, will be in the reply.
It is an error to request interfaces that are not supported by this Connection (i.e. mentioned in the ContactAttributeInterfaces property).
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.
Attributes from the interface org.freedesktop.Telepathy.Connection are always returned, and need not be requested explicitly.
As well as returning cached information immediately, the connection MAY start asynchronous requests to obtain better values for the contact attributes. If better values are later obtained by this process, they will be indicated with the usual signals (such as AliasesChanged).
Hold
−
b
Attributes
−
a{ua{sv}}
(Contact_Attributes_Map)A dictionary mapping the contact handles to contact attributes. If any of the requested handles are in fact invalid, they are simply omitted from this mapping. If contact attributes are not immediately known, the behaviour is defined by the interface; the attribute should either be omitted from the result or replaced with a default value.
Each contact's attributes will always include at least the
identifier that would be obtained by inspecting the handle
(org.freedesktop.Telepathy.Connection/contact-id
).
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidArgument
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ContactAttributeInterfaces
− as
(DBus_Interface[]), read-onlyAttribute
−
s
(Contact_Attribute)Value
−
v
Contact
−
u
(Contact_Handle)Attributes
−
a{sv}
(Single_Contact_Attributes_Map)This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
An interface on connections to support protocols which allow users to publish their current geographical location, and subscribe to the current location of their contacts.
This interface is geared strongly towards automatic propagation and use of this information, so focuses on latitude, longitude and altitude which can be determined by GPS, although provision is also included for an optional human-readable description of locations. All co-ordinate information is required to be relative to the WGS84 datum.
The information published through this interface is intended to have the same scope as presence information, so will normally be made available to those individuals on the user's "publish" contact list. Even so, user interfaces should not automatically publish location information without the consent of the user, and it is recommended that an option is made available to reduce the accuracy of the reported information to allow the user to maintain their privacy.
Location information is represented using the terminology of XMPP's XEP-0080 or the XEP-0080-derived Geoclue API where possible.
Added in version 0.17.18. (as a draft)
Contacts
−
au
(Contact_Handle[])Locations
−
a{ua{sv}}
(Contact_Locations)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
Contact
−
u
(Contact_Handle)Location
−
a{sv}
(Location)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.PermissionDenied
Location
−
a{sv}
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.PermissionDenied
Contact
−
u
(Contact_Handle)Location
−
a{sv}
(Location)Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
LocationAccessControlTypes
− au
(Rich_Presence_Access_Control_Type[]), read-onlyLocationAccessControl
− (uv)
(Rich_Presence_Access_Control), read/writeLocation_Accuracy_Level_None = 0
Location_Accuracy_Level_Country = 1
Location_Accuracy_Level_Region = 2
Location_Accuracy_Level_Locality = 3
Location_Accuracy_Level_Postal_Code = 4
Location_Accuracy_Level_Street = 5
Location_Accuracy_Level_Detailed = 6
Key
−
s
Civic addresses are represented by the following well-known keys (all of which have string values), which should be kept in sync with those used in XEP-0080 and in the Geoclue project:
The following address keys are defined in XEP-0080 but not by Geoclue, and are also allowed:
Positions are represented by the following well-known keys:
Velocities are represented by the following well-known keys:
Other well-known keys:
Value
−
v
Contact
−
u
(Contact_Handle)Location
−
a{sv}
(Location)Implementations of this interface must also implement:
This interface will become deprecated in future versions. New client implementations MAY use SimplePresence instead; new connection managers SHOULD implement both Presence and SimplePresence.
This interface is for services which have a concept of presence which can be published for yourself and monitored on your contacts. Telepathy's definition of presence is based on that used by the Galago project.
Presence on an individual (yourself or one of your contacts) is modelled as a last activity time along with a set of zero or more statuses, each of which may have arbitrary key/value parameters. Valid statuses are defined per connection, and a list of them can be obtained with the GetStatuses method.
Each status has an arbitrary string identifier which should have an agreed meaning between the connection manager and any client which is expected to make use of it. The following well-known values (in common with those in Galago) should be used where possible to allow clients to identify common choices:
As well as these well-known status identifiers, every status also has a numerical type value chosen from Connection_Presence_Type which can be used by the client to classify even unknown statuses into different fundamental types.
These numerical types exist so that even if a client does not understand the string identifier being used, and hence cannot present the presence to the user to set on themselves, it may display an approximation of the presence if it is set on a contact.
The dictionary of variant types allows the connection manager to exchange further protocol-specific information with the client. It is recommended that the string (s) argument 'message' be interpreted as an optional message which can be associated with a presence status.
If the connection has a 'subscribe' contact list, PresenceUpdate signals should be emitted to indicate changes of contacts on this list, and should also be emitted for changes in your own presence. Depending on the protocol, the signal may also be emitted for others such as people with whom you are communicating, and any user interface should be updated accordingly.
On some protocols, RequestPresence may only succeed on contacts on your 'subscribe' list, and other contacts will cause a PermissionDenied error. On protocols where there is no 'subscribe' list, and RequestPresence succeeds, a client may poll the server intermittently to update any display of presence information.
Status
−
s
Parameters
−
a{sv}
(String_Variant_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.PermissionDenied
Contacts
−
au
(Contact_Handle[])Presence
−
a{u(ua{sa{sv}})}
(Contact_Presences)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NotAvailable
Available_Statuses
−
a{s(ubba{ss})}
(Status_Spec_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Status
−
s
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.InvalidArgument
Contacts
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NotAvailable
Time
−
u
(Unix_Timestamp)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotImplemented
Statuses
−
a{sa{sv}}
(Multiple_Status_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
Presence
−
a{u(ua{sa{sv}})}
(Contact_Presences)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Connection_Presence_Type_Unset = 0
Connection_Presence_Type_Offline = 1
Connection_Presence_Type_Available = 2
Connection_Presence_Type_Away = 3
Connection_Presence_Type_Extended_Away = 4
Connection_Presence_Type_Hidden = 5
Connection_Presence_Type_Busy = 6
Added in version 0.17.0.
Connection_Presence_Type_Unknown = 7
Added in version 0.17.8.
Connection_Presence_Type_Error = 8
Added in version 0.17.8.
Rich_Presence_Access_Control_Type_Whitelist = 0
Rich_Presence_Access_Control_Type_Publish_List = 1
Rich_Presence_Access_Control_Type_Group = 2
Rich_Presence_Access_Control_Type_Open = 3
Arrays of Last_Activity_And_Statuses don't generally make sense.
Last_Activity
−
u
(Unix_Timestamp)Statuses
−
a{sa{sv}}
(Multiple_Status_Map)Arrays of Status_Spec don't generally make sense.
Type
−
u
(Connection_Presence_Type)May_Set_On_Self
−
b
Exclusive
−
b
Parameter_Types
−
a{ss}
(String_String_Map)Arrays of Rich_Presence_Access_Control don't generally make sense.
Type
−
u
(Rich_Presence_Access_Control_Type)Detail
−
v
Status
−
s
Parameters
−
a{sv}
(String_Variant_Map)Contact
−
u
(Contact_Handle)Presence
−
(ua{sa{sv}})
(Last_Activity_And_Statuses)Identifier
−
s
Spec
−
(ubba{ss})
(Status_Spec)This interface is not well-tested and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
An interface on connections to support protocols where the unique identifiers of contacts can change. Because handles are immutable, this is represented by a pair of handles, that representing the old name, and that representing the new one.Request that the user's own identifier is changed on the server. If successful, a Renamed signal will be emitted for the current "self handle" as returned by GetSelfHandle.
It is protocol-dependent how the identifier that's actually used will be derived from the supplied identifier; some sort of normalization might take place.
Name
−
s
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
Emitted when the unique identifier of a contact on the server changes.
Any channels associated with the contact's original handle will continue to be to that handle, and so are no longer useful (unless the contact renames back, or another contact connects with that unique ID). Clients may open a similar channel associated with the new handle to continue communicating with the contact.
For example, if a GUI client associates text channels with chat windows, it should detach the old channel from the chat window, closing it, and associate a channel to the new handle with the same window.
If the contact's old handle is in any of the member lists of a channel which has the groups interface, it will be removed from the channel and the new handle will be added. The resulting MembersChanged signal must be emitted after the Renamed signal; the reason should be RENAMED.
The handles may be either general-purpose or channel-specific. If the original handle is general-purpose, the new handle must be general-purpose; if the original handle is channel-specific, the new handle must be channel-specific in the same channel.
Original
−
u
(Contact_Handle)New
−
u
(Contact_Handle)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Implementations of this interface must also implement:
An enhanced version of the Telepathy connection interface, which can represent bundles of channels that should be dispatched together, and does not assume any particular properties by which channels are uniquely identifiable.
Added in version 0.17.11. (as stable API)
Request that an entirely new channel is created.
There is deliberately no flag corresponding to the suppress_handler argument to Connection.RequestChannel, because passing a FALSE value for that argument is deprecated. Requests made using this interface always behave as though suppress_handler was TRUE.
Added in version 0.17.11. (as stable API)
Changed in version 0.17.14: It is now guaranteed that CreateChannel returns the channel before NewChannels announces it (the reverse was previously guaranteed).
Request
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties, which MUST include ChannelType. Some properties are defined such that only an exact match makes sense, and connection managers MUST NOT satisfy a request with a channel where that property does not match; some properties are defined such that the connection manager MAY treat the request as merely a hint, and make a best-effort attempt to satisfy it. This is documented separately for each property.
If this dictionary contains a property whose semantics are not known to the connection manager, this method MUST fail without side-effects (in particular it must not create a new channel).
This is necessary if we want to be able to invent properties in future that, when used in a request, are hard requirements rather than just hints. A connection manager that did not know the semantics of those properties could incorrectly return a new channel that did not satisfy the requirements.
The connection manager MUST NOT respond successfully, and SHOULD NOT create a new channel or cause any other side-effects, unless it can create a new channel that satisfies the client's requirements.
Properties that will be set by this argument need not have write access after the channel has been created - indeed, it is expected that most will be read-only.
Channel
−
o
The Channel object, which MUST NOT be signalled with NewChannels until after this method returns.
This allows the requester to alter its handling of NewChannels by knowing whether one of the channels satisfied a request it made.
Properties
−
a{sv}
(Qualified_Property_Value_Map)Properties of the channel that was produced, equivalent to the properties in Channel_Details. Connection managers MUST NOT include properties here whose values can change, for the same reasons as in Channel_Details.
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotCapable
org.freedesktop.Telepathy.Error.NotAvailable
The requested channel cannot be created, but in principle, a similar request might succeed in future. For instance, this might be because:
org.freedesktop.Telepathy.Error.Channel.Banned
org.freedesktop.Telepathy.Error.Channel.Full
org.freedesktop.Telepathy.Error.Channel.InviteOnly
Request that channels are ensured to exist.
The connection manager is in the best position to determine which existing channels could satisfy which requests.
Added in version 0.17.12.
Changed in version 0.17.14: It is now guaranteed that if the channel was created by this call to EnsureChannel, it's returned before NewChannels announces it (the reverse was previously guaranteed).
Request
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties, with the same semantics as the corresponding parameter to CreateChannel.
Yours
−
b
If false, the caller of EnsureChannel MUST assume that some other process is handling this channel; if true, the caller of EnsureChannel SHOULD handle it themselves or delegate it to another client.
If the creation of a channel makes several calls to EnsureChannel (and no other requests) successful, exactly one of those calls MUST return a true value for this argument.
If the creation of a channel makes other requests successful, the value returned for this argument MUST be such that exactly one of the clients making requests ends up responsible for the channel. In particular, if CreateChannel returns a channel C, any EnsureChannel calls that also return C MUST return a false value for this argument.
Channel
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Properties of the channel that was produced, equivalent to the properties in Channel_Details. Connection managers MUST NOT include properties here whose values can change, for the same reasons as in Channel_Details.
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotCapable
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.Channel.Banned
org.freedesktop.Telepathy.Error.Channel.Full
org.freedesktop.Telepathy.Error.Channel.InviteOnly
New channels have been created. The connection manager SHOULD emit a single signal for any group of closely related channels that are created at the same time, so that the channel dispatcher can try to dispatch them to a handler as a unit.
In particular, if additional channels are created as a side-effect of a call to CreateChannel, these channels SHOULD appear in the same NewChannels signal as the channel that satisfies the request.
Joining a MUC Tube in XMPP requires joining the corresponding MUC (chatroom), so a Text channel can be created as a side-effect.
Every time NewChannels is emitted, it MUST be followed by a Connection.NewChannel signal for each channel.
The double signal emission is for the benefit of older Telepathy clients, which won't be listening for NewChannels.
The more informative NewChannels signal comes first so that clients that did not examine the connection to find out whether Requests is supported will see the more informative signal for each channel first, and then ignore the less informative signal because it announces a new channel of which they are already aware.
Added in version 0.17.11. (as stable API)
Changed in version 0.17.14: Added a guarantee of ordering relative to NewChannel
Channels
−
a(oa{sv})
(Channel_Details[])Added in version 0.17.11. (as stable API)
Removed
−
o
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Channels
− a(oa{sv})
(Channel_Details[]), read-onlyAdded in version 0.17.11. (as stable API)
RequestableChannelClasses
− a(a{sv}as)
(Requestable_Channel_Class[]), read-onlyThe classes of channel that are expected to be available on this connection, i.e. those for which CreateChannel can reasonably be expected to succeed. User interfaces can use this information to show or hide UI components.
This property cannot change after the connection has gone to state Connection_Status_Connected, so there is no change notification (if the connection has context-dependent capabilities, it SHOULD advertise support for all classes of channel that it might support during its lifetime). Before this state has been reached, the value of this property is undefined.
This is not on an optional interface, because connection managers can always offer some sort of clue about the channel classes they expect to support (at worst, they can announce support for everything for which they have code).
Added in version 0.17.11. (as stable API)
Added in version 0.17.11. (as stable API)
In bindings that need a separate name, arrays of Channel_Details should be called Channel_Details_List.
Channel
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Properties of the channel.
Connection managers MUST NOT include properties in this mapping if their values can change. Clients MUST ignore properties that appear in this mapping if their values can change.
If properties that could change were included, the following race condition would be likely to exist in some cases:
We've taken the opportunity to make the API encourage the client author to get it right. Where possible, we intend that properties whose value will be used in channel dispatching or other "early" processing will be defined so that they are immutable (can never change).
Each dictionary MUST contain the keys org.freedesktop.Telepathy.Channel.ChannelType, org.freedesktop.Telepathy.Channel.TargetHandleType, org.freedesktop.Telepathy.Channel.TargetHandle, org.freedesktop.Telepathy.Channel.TargetID and org.freedesktop.Telepathy.Channel.Requested.
We expect these to be crucial to the channel-dispatching process.
Structure representing a class of channels that can be requested, identified by a set of properties that identify that class of channel.
This will often just be the channel type and the handle type, but can include other properties of the channel - for instance, encrypted channels might require properties that unencrypted channels do not, like an encryption key.
In some cases, these classes of channel may overlap, in the sense that one class fixes all the properties that another class does, plus some more properties.
For older clients to still be able to understand how to request channels in the presence of a hypothetical "encryption" interface, we'd need to represent it like this:
Added in version 0.17.11. (as stable API)
In bindings that need a separate name, arrays of Requestable_Channel_Class should be called Requestable_Channel_Class_List.
Fixed_Properties
−
a{sv}
(Channel_Class)The property values that identify this requestable channel class. These properties MUST be included in requests for a channel of this class, and MUST take these values.
Clients that do not understand the semantics of all the Fixed_Properties MUST NOT request channels of this class, since they would be unable to avoid making an incorrect request.
This implies that connection managers wishing to make channels available to old or minimal clients SHOULD have a channel class with the minimum number of Fixed_Properties, and MAY additionally have channel classes with extra Fixed_Properties.
Allowed_Properties
−
as
(DBus_Qualified_Member[])Properties that MAY be set when requesting a channel of this channel type and handle type.
This array MUST NOT include properties that are in the Fixed_Properties mapping.
Properties in this array may either be required or optional, according to their documented semantics.
For instance, if TargetHandleType takes a value that is not Handle_Type_None, one or the other of TargetHandle and TargetID is required. Clients are expected to understand the documented relationship between the properties, so we do not have separate arrays of required and optional properties.
If this array contains the Bundle property, then this class of channel can be combined with other channels with that property in a request, or added to an existing bundle. If not, this signifies that the connection manager is unable to mark channels of this class as part of a bundle - this means that to the remote contact they are likely to be indistinguishable from channels requested separately.
Mapping representing a class of channels that can be requested from a connection manager, can be handled by a user interface, are supported by a contact, etc.
Classes of channel are identified by the fixed values of a subset of their properties.
Channel classes SHOULD always include the keys org.freedesktop.Telepathy.Channel.ChannelType and org.freedesktop.Telepathy.Channel.TargetHandleType.
In bindings that need a separate name, arrays of Channel_Class should be called Channel_Class_List.
Key
−
s
(DBus_Qualified_Member)Value
−
v
Implementations of this interface must also implement:
This interface is for services which have a concept of presence which can be published for yourself and monitored on your contacts.
Presence on an individual (yourself or one of your contacts) is modelled as a status and a status message. Valid statuses are defined per connection, and a list of those that can be set on youself can be obtained from the Statuses property.
Each status has an arbitrary string identifier which should have an agreed meaning between the connection manager and any client which is expected to make use of it. The following well-known values should be used where possible to allow clients to identify common choices:
status identifier | Connection_Presence_Type | comments |
---|---|---|
available | Connection_Presence_Type_Available | |
away | Connection_Presence_Type_Away | |
brb | Connection_Presence_Type_Away | Be Right Back (a more specific form of Away) |
busy | Connection_Presence_Type_Busy | |
dnd | Connection_Presence_Type_Busy | Do Not Disturb (a more specific form of Busy) |
xa | Connection_Presence_Type_Extended_Away | Extended Away |
hidden | Connection_Presence_Type_Hidden | Also known as "Invisible" or "Appear Offline" |
offline | Connection_Presence_Type_Offline | |
unknown | Connection_Presence_Type_Unknown | special, see below |
error | Connection_Presence_Type_Error | special, see below |
As well as these well-known status identifiers, every status also has a numerical type value chosen from Connection_Presence_Type which can be used by the client to classify even unknown statuses into different fundamental types.
These numerical types exist so that even if a client does not understand the string identifier being used, and hence cannot present the presence to the user to set on themselves, it may display an approximation of the presence if it is set on a contact.
As well as the normal status identifiers, there are two special ones that may be present: 'unknown' with type Unknown and 'error' with type Error. 'unknown' indicates that it is impossible to determine the presence of a contact at this time, for example because it's not on the 'subscribe' list and the protocol only allows one to determine the presence of contacts you're subscribed to. 'error' indicates that there was a failure in determining the status of a contact.
If the connection has a 'subscribe' contact list, PresencesChanged signals should be emitted to indicate changes of contacts on this list, and should also be emitted for changes in your own presence. Depending on the protocol, the signal may also be emitted for others such as people with whom you are communicating, and any user interface should be updated accordingly.
Request that the presence status and status message are published for the connection. Changes will be indicated by PresencesChanged signals being emitted.
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 selected status.
In DISCONNECTED state the Statuses property will indicate which statuses are allowed to be set while DISCONNECTED (none, if the Connection Manager doesn't allow this). This value MUST NOT be cached, as the set of allowed presences might change upon connecting.
Status
−
s
The string identifier of the desired status. Possible status identifiers are defined in the Statuses property.
Clients MUST NOT set a status whose string value they do not recognise, even if its presence type in Statuses matches what the user requested.
Suppose a protocol has statuses that include 'phone' (of type BUSY) and 'in-a-meeting' (of type BUSY), but there is no generic 'busy' status.
If the user requests "Busy" status from a menu, a client author might be tempted to pick an arbitrary status that has type BUSY. However, on this protocol, neither of the choices would be appropriate, and incorrect information about the user would be conveyed.
Status_Message
−
s
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Contacts
−
au
(Contact_Handle[])Presence
−
a{u(uss)}
(Simple_Contact_Presences)Presence information in the same format as for the PresencesChanged signal. The returned mapping MUST include an entry for each contact in the method's argument.
The definition of the connection presence types Unknown and Offline means that if a connection manager will return Unknown for contacts not on the subscribe list, it MUST delay the reply to this method call until it has found out which contacts are, in fact, on the subscribe list.
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
Presence
−
a{u(uss)}
(Simple_Contact_Presences)Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Statuses
− a{s(ubb)}
(Simple_Status_Spec_Map), read-onlyA dictionary where the keys are the presence statuses that the user can set on themselves for this connection, and the values are the corresponding presence types.
While the connection is in the DISCONNECTED state, it contains the set of presence statuses allowed to be set before connecting. The connection manager will attempt to set the appropriate status when the connection becomes connected, but cannot necessarily guarantee it. The available statuses cannot change until the connection status changes, so there is no change notification.
While the connection is in the CONNECTED state, this property contains the set of presence statuses which are actually available on this protocol. This set is constant for the remaining lifetime of the connection, so again, there is no change notification.
While the connection is in the CONNECTING state, the value of this property is undefined and SHOULD NOT be used. It can change at any time without notification (in particular, any cached values from when the connection was in the DISCONNECTED or CONNECTING state MUST NOT be assumed to still be correct when the state has become CONNECTED).
This property MUST include the special statuses "unknown" and "error" if and only if the connection manager can emit them as a contact's status.
Arrays of Simple_Presence don't generally make sense.
Type
−
u
(Connection_Presence_Type)Status
−
s
Status_Message
−
s
The user-defined status message, e.g. "Back soon!".
Clients SHOULD set the status message for the local user to the empty string, unless the user has actually provided a specific message (i.e. one that conveys more information than the Status).
User interfaces SHOULD regard an empty status message as unset, and MAY replace it with a localized string corresponding to the Status or Type.
Arrays of Simple_Status_Spec don't generally make sense.
Type
−
u
(Connection_Presence_Type)May_Set_On_Self
−
b
Can_Have_Message
−
b
Contact
−
u
(Contact_Handle)Presence
−
(uss)
(Simple_Presence)Identifier
−
s
Spec
−
(ubb)
(Simple_Status_Spec)This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
A group of related channels, which should all be dispatched to the same handler if possible.
Bundles currently have no functionality of their own, so clients SHOULD NOT examine this interface, but should instead treat the bundle object-path as an opaque identifier. If more functionality is added to bundles in future, this interface will be used for capability discovery.
The lifetime of a bundle is defined by its component channels - as long as one or more channels whose Bundle property is B exist, the bundle B will also exist.
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyAll communication in the Telepathy framework is carried out via channel objects which are created and managed by connections. This interface must be implemented by all channel objects, along with one single channel type, such as Channel.Type.ContactList which represents a list of people (such as a buddy list) or a Channel.Type.Text which represents a channel over which textual messages are sent and received.
Each Channel's object path MUST start with the object path of its associated Connection, followed by '/'. There MAY be any number of additional object-path components, which clients MUST NOT attempt to parse.
This ensures that Channel object paths are unique, even between Connections and CMs, because Connection object paths are guaranteed-unique via their link to the well-known bus name.
If all connection managers in use are known to comply with at least spec version 0.17.10, then the Connection's object path can even be determined from the Channel's without any additional information, by taking the first 7 components.
Each channel may have an immutable handle associated with it, which may be any handle type, such as a contact, room or list handle, indicating that the channel is for communicating with that handle.
If a channel does not have a handle (an "anonymous channel" with Target_Handle = 0 and Target_Handle_Type = Handle_Type_None), it means that the channel is defined by some other terms, such as it may be a transient group defined only by its members as visible through the Channel.Interface.Group interface.
Other optional interfaces can be implemented to indicate other available functionality, such as Channel.Interface.Group if the channel contains a number of contacts, Channel.Interface.Password to indicate that a channel may have a password set to require entry, and Properties for extra data about channels which represent chat rooms or voice calls. The interfaces implemented may not vary after the channel's creation has been signalled to the bus (with the connection's NewChannel signal).
Specific connection manager implementations may implement channel types and interfaces which are not contained within this specification in order to support further functionality. To aid interoperability between client and connection manager implementations, the interfaces specified here should be used wherever applicable, and new interfaces made protocol-independent wherever possible. Because of the potential for 3rd party interfaces adding methods or signals with conflicting names, the D-Bus interface names should always be used to invoke methods and bind signals.
Changed in version 0.17.7: Previously we guaranteed that, for any handle type other than Handle_Type_None, and for any channel type and any handle, there would be no more than one channel with that combination of channel type, handle type and handle. This guarantee has now been removed in order to accommodate features like message threads.
Changed in version 0.17.10: Previously we did not explicitly guarantee that Channels' object paths had the Connection's object path as a prefix.
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.NotAvailable
Deprecated since version 0.17.7. Use the ChannelType property if possible.
Channel_Type
−
s
(DBus_Interface)Deprecated since version 0.17.7. Use the TargetHandleType and TargetHandle properties if possible.
Target_Handle_Type
−
u
(Handle_Type)Target_Handle
−
u
(Handle)Deprecated since version 0.17.7. Use the Interfaces property if possible.
Interfaces
−
as
(DBus_Interface[])Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ChannelType
− s
(DBus_Interface), read-onlyThe channel's type. This cannot change once the channel has been created.
For compatibility between older connection managers and newer clients, if this is unavailable or is an empty string, clients MUST use the result of calling GetChannelType.
When requesting a channel, the request MUST specify a channel type, and the request MUST fail if the specified channel type cannot be supplied.
Added in version 0.17.7.
Interfaces
− as
(DBus_Interface[]), read-onlyExtra interfaces provided by this channel. This SHOULD NOT include the channel type and the Channel interface itself, and cannot change once the channel has been created.
For compatibility between older connection managers and newer clients, if this is unavailable, or if this is an empty list and ChannelType is an empty string, clients MUST use the result of calling GetInterfaces instead. If this is an empty list but ChannelType is non-empty, clients SHOULD NOT call GetInterfaces; this implies that connection managers that implement the ChannelType property MUST also implement the Interfaces property correctly.
When requesting a channel with a particular value for this property, the request must fail without side-effects unless the connection manager expects to be able to provide a channel whose interfaces include at least the interfaces requested.
Added in version 0.17.7.
TargetHandle
− u
(Handle), read-onlyThe handle (a representation for the identifier) of the contact, chatroom, etc. with which this handle communicates. Its type is given by the TargetHandleType property.
This is fixed for the lifetime of the channel, so channels which could potentially be used to communicate with multiple contacts (such as streamed media calls defined by their members, or ad-hoc chatrooms like MSN switchboards) must have TargetHandleType set to Handle_Type_None and TargetHandle set to 0.
Unlike in the telepathy-spec 0.16 API, there is no particular uniqueness guarantee - there can be many channels with the same (channel type, handle type, handle) tuple. This is necessary to support conversation threads in XMPP and SIP, for example.
If this is present in a channel request, it must be nonzero, TargetHandleType MUST be present and not Handle_Type_None, and TargetID MUST NOT be present.
The channel that satisfies the request MUST either:
Added in version 0.17.7.
TargetID
− s
, read-onlyThe string that would result from inspecting the TargetHandle property (i.e. the identifier in the IM protocol of the contact, room, etc. with which this channel communicates), or the empty string if the TargetHandle is 0.
The presence of this property avoids the following race condition:
If this is present in a channel request, TargetHandleType MUST be present and not Handle_Type_None, and TargetHandle MUST NOT be present. The request MUST fail with error InvalidHandle, without side-effects, if the requested TargetID would not be accepted by RequestHandles.
The returned channel must be related to the handle corresponding to the given identifier, in the same way as if TargetHandle had been part of the request instead.
Requesting channels with a string identifier saves a round-trip (the call to RequestHandles). It also allows the channel dispatcher to accept a channel request for an account that is not yet connected (and thus has no valid handles), bring the account online, and pass on the same parameters to the new connection's CreateChannel method.
Added in version 0.17.9.
TargetHandleType
− u
(Handle_Type), read-onlyThe type of TargetHandle.
If this is omitted from a channel request, connection managers SHOULD treat this as equivalent to Handle_Type_None.
If this is omitted or is Handle_Type_None, TargetHandle and TargetID MUST be omitted from the request.
Added in version 0.17.7.
Requested
− b
, read-onlyTrue if this channel was created in response to a local request, such as a call to Connection.RequestChannel or Connection.Interface.Requests.CreateChannel.
The idea of this property is to distinguish between "incoming" and "outgoing" channels, in a way that doesn't break down when considering special cases like contact lists that are automatically created on connection to the server, or chatrooms that an IRC proxy/bouncer like irssi-proxy or bip was already in.
The reason we want to make that distinction is that UIs for things that the user explicitly requested should start up automatically, whereas for incoming messages and VoIP calls we should first ask the user whether they want to open the messaging UI or accept the call.
If the channel was not explicitly requested (even if it was created as a side-effect of a call to one of those functions, e.g. because joining a Tube in a MUC context on XMPP implies joining that MUC), then this property is false.
For compatibility with older connection managers, clients SHOULD assume that this property is true if they see a channel announced by the Connection.NewChannel signal with the suppress_handler parameter set to true.
In a correct connection manager, the only way to get such a channel is to request it.
Clients MAY additionally assume that this property is false if they see a channel announced by the NewChannel signal with the suppress_handler parameter set to false.
This is more controversial, since it's possible to get that parameter set to false by requesting a channel. However, there's no good reason to do so, and we've deprecated this practice.
In the particular case of the channel dispatcher, the only side-effect of wrongly thinking a channel is unrequested is likely to be that the user has to confirm that they want to use it, so it seems fairly harmless to assume in the channel dispatcher that channels with suppress_handler false are indeed unrequested.
It does not make sense for this property to be in channel requests—it will always be true for channels returned by CreateChannel, and callers of EnsureChannel cannot control whether an existing channel was originally requested locally—so it MUST NOT be accepted.
Added in version 0.17.13. (as stable API)
InitiatorHandle
− u
(Contact_Handle), read-onlyThe contact who initiated the channel. For channels requested by the local user, this MUST be the value of Connection.SelfHandle at the time the channel was created (i.e. not a channel-specific handle).
The careful wording about the self-handle is because the Renaming interface can cause the return from Connection.GetSelfHandle to change. It's something of a specification bug that we don't signal this in the Connection interface yet.
For channels requested by a remote user, this MUST be their handle. If unavailable or not applicable, this MUST be 0 (for instance, contact lists are not really initiated by anyone in particular, and it's easy to imagine a protocol where chatroom invitations can be anonymous).
For channels with the Group interface, this SHOULD be the same contact who is signalled as the "Actor" causing the self-handle to be placed in the local-pending set.
This SHOULD NOT be a channel-specific handle, if possible.
It does not make sense for this property to be in channel requests - the initiator will always be the local user - so it MUST NOT be accepted.
Added in version 0.17.13. (as stable API)
InitiatorID
− s
, read-onlyThe string that would result from inspecting the InitiatorHandle property (i.e. the initiator's identifier in the IM protocol).
The presence of this property avoids the following race condition:
It does not make sense for this property to be in channel requests - the initiator will always be the local user - so it MUST NOT be accepted.
Added in version 0.17.13. (as stable API)
This interface is a staging area for future Channel functionality and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
This interface contains functionality which we intend to incorporate into the Channel interface in future. It should be considered to be conceptually part of the core Channel interface, but without API or ABI guarantees.
If we add new functionality to the Channel interface, libraries that use generated code (notably telepathy-glib) will have it as part of their ABI forever, meaning we can't make incompatible changes. By using this interface as a staging area for future Channel functionality, we can try out new properties, signals and methods as application-specific extensions, then merge them into the core Channel interface when we have enough implementation experience to declare them to be stable.
The name is by analogy to Python's __future__
pseudo-module.
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Bundle
− o
, read-onlyThe ChannelBundle to which this channel belongs.
A channel's Bundle property can never change.
Older connection managers might not have this property. Clients (particularly the channel dispatcher) SHOULD recover by considering each channel to be in a bundle containing only that channel, distinct from all other bundles, which has no additional interfaces.
Added in version 0.17.9. (in Channel.FUTURE pseudo-interface)
Implementations of this interface must also implement:
A channel type for representing a list of people on the server which is not used for communication. This is intended for use with the interface Channel.Interface.Group for managing buddy lists and privacy lists on the server. This channel type has no methods because all of the functionality it represents is available via the group interface.
There are currently two types of contact list: HANDLE_TYPE_LIST is a "magic" server-defined list, and HANDLE_TYPE_GROUP is a user-defined contact group.
For server-defined lists like the subscribe list, singleton instances of this channel type should be created by the connection manager at connection time if the list exists on the server, or may be requested by using the appropriate handle. These handles can be obtained using RequestHandles with a Handle_Type of HANDLE_TYPE_LIST and one of the following identifiers:
A contact can be in several server-defined lists. All lists are optional to implement. If RequestHandles or RequestChannel for a particular contact list raises an error, this indicates that the connection manager makes no particular statement about the list's contents; clients MUST NOT consider this to be fatal.
If a client wants to list all of a user's contacts, it is appropriate to use the union of the subscribe, publish and stored lists, including the local and remote pending members.
For example in XMPP, contacts who have the subscription type "none", "from", "to" and "both" can be respectively in the lists:
These contact list channels may not be closed.
For user-defined contact groups, instances of this channel type should be created by the connection manager at connection time for each group that exists on the server. New, empty groups can be created by calling RequestHandles with a Handle_Type of HANDLE_TYPE_GROUP and with the name set to the human-readable UTF-8 name of the group.
User-defined groups may be deleted by calling Close on the channel, but only if the group is already empty. Closing a channel to a non-empty group is not allowed; its members must be set to the empty set first.
On some protocols (e.g. XMPP) empty groups are not represented on the server, so disconnecting from the server and reconnecting might cause empty groups to vanish.
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Implementations of this interface must also implement:
A channel that can send and receive streamed media such as audio or video. Provides a number of methods for listing and requesting new streams, and signals to indicate when streams have been added, removed and changed status.
To make a media call to a contact, clients should call CreateChannel with ChannelType = StreamedMedia, TargetHandleType = Contact, and one of TargetHandle or TargetID (which should yield a channel with the local user in Members, and the remote contact as TargetHandle but not in any group members list), then call RequestStreams to initiate the call (at which point the contact should appear in the channel's RemotePendingMembers).
Incoming calls should be signalled as TargetHandleType = Contact, TargetHandle set to the remote contact, with the local user in LocalPendingMembers; to accept the call, AddMembers can be used to move the local user to the group's members.
In the past, several other patterns have been used to place outgoing calls; see 'Requesting StreamedMedia Channels' on the Telepathy wiki for the details.
In general this should be used in conjunction with the MediaSignalling interface to exchange connection candidates and codec choices with whichever component is responsible for the streams. However, in certain applications where no candidate exchange is necessary (eg the streams are 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.
Streams
−
a(uuuuuu)
(Media_Stream_Info[])Streams
−
au
(Stream_ID[])org.freedesktop.Telepathy.Error.InvalidArgument
Request a change in the direction of an existing stream. In particular, this might be useful to stop sending media of a particular type, or inform the peer that you are no longer using media that is being sent to you.
Depending on the protocol, streams which are no longer sending in either direction should be removed and a StreamRemoved signal emitted. Some direction changes can be enforced locally (for example, BIDIRECTIONAL -> RECEIVE can be achieved by merely stopping sending), others may not be possible on some protocols, and some need agreement from the remote end. In this case, the MEDIA_STREAM_PENDING_REMOTE_SEND flag will be set in the StreamDirectionChanged signal, and the signal emitted again without the flag to indicate the resulting direction when the remote end has accepted or rejected the change.
Stream_ID
−
u
Stream_Direction
−
u
(Media_Stream_Direction)org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Request that streams be established to exchange the given types of media with the given member. In general this will try and establish a bidirectional stream, but on some protocols it may not be possible to indicate to the peer that you would like to receive media, so a send-only stream will be created initially. In the cases where the stream requires remote agreement (eg you wish to receive media from them), the StreamDirectionChanged signal will be emitted with the MEDIA_STREAM_PENDING_REMOTE_SEND flag set, and the signal emitted again with the flag cleared when the remote end has replied.
If streams of the requested types have already been requested via this method or FUTURE.InitialAudio/FUTURE.InitialVideo, this method SHOULD return successfully.
Changed in version 0.17.2: It is valid to use a handle which is neither a current nor pending member in this channel's Group interface. If so, that handle will be added to the remote-pending set only when an attempt has actually been made to contact them. For further call-state notification, use the CallState interface, if supported. This usage was not allowed in spec versions below 0.17.2.
Contact_Handle
−
u
(Contact_Handle)Types
−
au
(Media_Stream_Type[])Streams
−
a(uuuuuu)
(Media_Stream_Info[])org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Stream_ID
−
u
Contact_Handle
−
u
(Contact_Handle)Stream_Type
−
u
(Media_Stream_Type)Stream_ID
−
u
Stream_Direction
−
u
(Media_Stream_Direction)Pending_Flags
−
u
(Media_Stream_Pending_Send)Stream_ID
−
u
Error_Code
−
u
(Media_Stream_Error)Message
−
s
Stream_ID
−
u
Stream_ID
−
u
Stream_State
−
u
(Media_Stream_State)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Media_Stream_Type_Audio = 0
Media_Stream_Type_Video = 1
Media_Stream_State_Disconnected = 0
Media_Stream_State_Connecting = 1
Media_Stream_State_Connected = 2
Media_Stream_Direction_None = 0
Media_Stream_Direction_Send = 1
Media_Stream_Direction_Receive = 2
Media_Stream_Direction_Bidirectional = 3
Media_Stream_Pending_Local_Send = 1
Media_Stream_Pending_Remote_Send = 2
Channel_Media_Capability_Audio = 1
Channel_Media_Capability_Video = 2
Channel_Media_Capability_NAT_Traversal_STUN = 4
Channel_Media_Capability_NAT_Traversal_GTalk_P2P = 8
In bindings that need a separate name, arrays of Media_Stream_Info should be called Media_Stream_Info_List.
Identifier
−
u
(Stream_ID)Contact
−
u
(Contact_Handle)Type
−
u
(Media_Stream_Type)State
−
u
(Media_Stream_State)Direction
−
u
(Media_Stream_Direction)Pending_Send_Flags
−
u
(Media_Stream_Pending_Send)Implementations of this interface must also implement:
This interface contains functionality which we intend to incorporate into the Channel.Type.StreamedMedia interface in future. It should be considered to be conceptually part of the core StreamedMedia interface, but without API or ABI guarantees.
The rationale is the same as for Channel.FUTURE.
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
InitialAudio
− b
, read-onlyIf set to true in a channel request that will create a new channel, the connection manager should immediately attempt to establish an audio stream to the remote contact, making it unnecessary for the client to call RequestStreams.
If this property, or InitialVideo, is passed to EnsureChannel (as opposed to CreateChannel), the connection manager SHOULD ignore these properties when checking whether it can return an existing channel as suitable; these properties only become significant when the connection manager has decided to create a new channel.
If true on a requested channel, this indicates that the audio stream has already been requested and the client does not need to call RequestStreams, although it MAY still do so.
If true on an unrequested (incoming) channel, this indicates that the remote contact initially requested an audio stream; this does not imply that that audio stream is still active (as indicated by ListStreams).
This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. NewChannels signals.
This reduces D-Bus round trips.
Connection managers capable of signalling audio calls to contacts SHOULD include a channel class in RequestableChannelClasses with ChannelType = StreamedMedia and TargetHandleType = 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.
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.
Connection managers that support the ContactCapabilities.DRAFT 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 in the fixed properties dictionary, and InitialAudio and/or InitialVideo in the allowed properties list. Clients wishing to discover whether a particular contact is likely to be able to receive audio and/or video calls SHOULD use this information.
Not all clients support video calls, and it would also be possible (although unlikely) to have a client which could only stream video, not audio.
Clients that are willing to receive audio and/or video calls SHOULD include the following filters if calling SetSelfCapabilities (clients of a ChannelDispatcher.DRAFT SHOULD instead arrange for the ChannelDispatcher to do this, by including the filters in their HandlerChannelFilter properties):
Connection managers for protocols with capability discovery, like XMPP, need this information to advertise the appropriate capabilities for their protocol.
If { ChannelType = StreamedMedia } is passed to SetSelfCapabilities, but no more specific channel class for audio or video has been passed to that method (in the presence of a ChannelDispatcher, this would mean that there is at least one client with that channel class in its HandlerChannelFilter, but no installed client has the more specific channel classes in its HandlerChannelFilter), then the connection manager SHOULD advertise support for every content type (audio or video) that it supports.
This lowers the "barrier to entry" by allowing a simple client to say merely that it supports streamed media at all.
InitialVideo
− b
, read-onlyThe same as InitialAudio, but for a video stream. This property is immutable (cannot change).
In particular, note that if this property is false, this does not imply that an active video stream has not been added, only that no video stream was active at the time the channel appeared.
This property is the correct way to discover whether connection managers, contacts etc. support video calls; it appears in capabilities structures in the same way as InitialAudio.
Implementations of this interface must also implement:
A channel type for listing named channels available on the server. Once the ListRooms method is called, it emits signals for rooms present on the server, until you Close this channel. In some cases, it may not be possible to stop the deluge of information from the server. This channel should be closed when the room information is no longer being displayed, so that the room handles can be freed.
This channel type may be implemented as a singleton on some protocols, so clients should be prepared for the eventuality that they are given a channel that is already in the middle of listing channels. The ListingRooms signal, or GetListingRooms method, can be used to check this.
In_Progress
−
b
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
Emitted when information about rooms on the server becomes available. The array contains the room handle (as can be passed to the RequestChannel method with HANDLE_TYPE_ROOM), the channel type, and a dictionary containing further information about the room as available. The following well-known keys and types are recommended for use where appropriate:
Rooms
−
a(usa{sv})
(Room_Info[])Listing
−
b
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Server
− s
, read-onlyIn bindings that need a separate name, arrays of Room_Info should be called Room_Info_List.
Handle
−
u
(Room_Handle)Channel_Type
−
s
(DBus_Interface)Info
−
a{sv}
(String_Variant_Map)Implementations of this interface must also implement:
A channel type for sending and receiving messages in plain text, with no formatting. In future specifications, channels for sending and receiving messages that can be reduced to plain text (i.e. formatted text) should also have this type.
When a message is received, an identifier is assigned and a Received signal emitted, and the message placed in a pending queue which can be inspected with ListPendingMessages. A client which has handled the message by showing it to the user (or equivalent) should acknowledge the receipt using the AcknowledgePendingMessages method, and the message will then be removed from the pending queue. Numeric identifiers for received messages may be reused over the lifetime of the channel.
Each message has an associated 'type' value, which should be one of the values allowed by Channel_Text_Message_Type.
Each message also has a flags value, which is a bitwise OR of the flags given in Channel_Text_Message_Flags.
Sending messages can be requested using the Send method, which will return successfully and emit the Sent signal when the message has been delivered to the server, or return an error with no signal emission if there is a failure. If a message is sent but delivery of the message later fails, this is indicated with the SendError signal.
On protocols where additional contacts cannot be invited into a one-to-one chat, or where a one-to-one chat is just a series of individual personal messages rather than being represented by some object on the server (i.e. most protocols), one-to-one chats should be represented by a Text channel with Handle_Type CONTACT.
Named chat rooms whose identity can be saved and used again later (IRC channels, Jabber MUCs) are expected to be represented by Text channels with Handle_Type ROOM and the Group interface; they should usually also have the Properties interface.
Unnamed, transient chat rooms defined only by their members (e.g. on MSN) are expected to be represented by Text channels with handle type 0, handle 0, the Group interface, and optionally the Properties interface.
On protocols where a conversation with a user is actually just a nameless chat room starting with exactly two members, to which more members can be invited, calling RequestChannel with type Text and handle type CONTACT should continue to succeed, but may return a channel with handle type 0, handle 0, the group interface, and the local and remote contacts in its members.
If a channel of type Text is closed while it has pending messages, the connection manager MUST allow this, but SHOULD open a new, identical channel to deliver those messages, signalling it as a new channel with the NewChannel signal (with the suppress_handler parameter set to FALSE).
If messages were sent on the old channel but the Sentsignal has not yet been emitted for those messages, the new channel SHOULD emit Sent for those messages when appropriate - it behaves like a continuation of the old channel.
In effect, this turns this situation, in which a client is likely to lose messages:
into something nearly equivalent to this situation, which is fine:
suppress_handler must be set to FALSE so the replacement channel will be handled by something.
As a result, Text channels SHOULD implement Channel.Interface.Destroyable.
This "respawning" behaviour becomes problematic if there is no suitable handler for Text channels, or if a particular message repeatedly crashes the Text channel handler; a channel dispatcher can't just Close() the channel in these situations, because it will come back.
In these situations, the channel dispatcher needs a last-resort way to destroy the channel and stop it respawning. It could either acknowledge the messages itself, or use the Destroyable interface; the Destroyable interface has the advantage that it's not channel-type-dependent, so the channel dispatcher only has to understand one extra interface, however many channel types eventually need a distinction between Close and Destroy.
IDs
−
au
(Message_ID[])org.freedesktop.Telepathy.Error.InvalidArgument
Available_Types
−
au
(Channel_Text_Message_Type[])Clear
−
b
Pending_Messages
−
a(uuuuus)
(Pending_Text_Message[])Request that a message be sent on this channel. When the message has been submitted for delivery, this method will return and the Sent signal will be emitted. If the message cannot be submitted for delivery, the method returns an error and no signal is emitted.
This method SHOULD return before the Sent signal is emitted.
When a Text channel implements the Messages interface, that "SHOULD" becomes a "MUST".
Type
−
u
(Channel_Text_Message_Type)Text
−
s
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
ID
−
u
Timestamp
−
u
(Unix_Timestamp)Sender
−
u
(Contact_Handle)Type
−
u
(Channel_Text_Message_Type)Flags
−
u
(Channel_Text_Message_Flags)Text
−
s
Signals that an outgoing message has failed to send. The error will be one of the values from ChannelTextSendError.
This signal should only be emitted for messages for which Sent has already been emitted and Send has already returned success.
Changed in version 0.17.3: older spec versions claimed that SendError was emitted instead of Sent, rather than in addition to Sent. However, the 0.17.3+ semantics were what we'd always actually implemented.
Error
−
u
(Channel_Text_Send_Error)Timestamp
−
u
(Unix_Timestamp)Type
−
u
(Channel_Text_Message_Type)Text
−
s
Signals that a message has been submitted for sending.
Timestamp
−
u
(Unix_Timestamp)Type
−
u
(Channel_Text_Message_Type)Text
−
s
Accessed using the Telepathy Properties interface.
anonymous
−
b
invite-only
−
b
limit
−
u
limited
−
b
moderated
−
b
name
−
s
description
−
s
password
−
s
password-required
−
b
persistent
−
b
private
−
b
subject
−
s
subject-contact
−
u
subject-timestamp
−
u
Interface has no D-Bus core properties.
Channel_Text_Send_Error_Unknown = 0
Channel_Text_Send_Error_Offline = 1
Channel_Text_Send_Error_Invalid_Contact = 2
Channel_Text_Send_Error_Permission_Denied = 3
Channel_Text_Send_Error_Too_Long = 4
Channel_Text_Send_Error_Not_Implemented = 5
Channel_Text_Message_Type_Normal = 0
Channel_Text_Message_Type_Action = 1
Channel_Text_Message_Type_Notice = 2
Channel_Text_Message_Type_Auto_Reply = 3
Channel_Text_Message_Type_Delivery_Report = 4
Channel_Text_Message_Flag_Truncated = 1
Channel_Text_Message_Flag_Non_Text_Content = 2
The incoming message contained non-text content which cannot be represented by this interface, but has been signalled in the Messages interface.
Connection managers SHOULD only set this flag if the non-text content appears to be relatively significant (exactly how significant is up to the implementor). The intention is that if this flag is set, clients using this interface SHOULD inform the user that part of the message was not understood.
Channel_Text_Message_Flag_Scrollback = 4
The incoming message was part of a replay of message history.
In XMPP multi-user chat, a few past messages are replayed when you join a chatroom. A sufficiently capable IRC connection manager could also set this flag on historical messages when connected to a proxy like bip or irssi-proxy. The existence of this flag allows loggers and UIs to use better heuristics when eliminating duplicates (a simple implementation made possible by this flag would be to avoid logging scrollback at all).
Channel_Text_Message_Flag_Rescued = 8
The incoming message has been seen in a previous channel during the lifetime of the Connection, but had not been acknowledged when that channel closed, causing an identical channel (the channel in which the message now appears) to open.
This means that a logger (which should already have seen the message in the previous channel) is able to recognise and ignore these replayed messages.
In bindings that need a separate name, arrays of Pending_Text_Message should be called Pending_Text_Message_List.
Identifier
−
u
(Message_ID)Unix_Timestamp
−
u
(Unix_Timestamp)Sender
−
u
(Contact_Handle)Message_Type
−
u
(Channel_Text_Message_Type)Flags
−
u
(Channel_Text_Message_Flags)Text
−
s
Implementations of this interface must also implement:
A "tube" is a mechanism for arbitrary data transfer. Two types of data transfer are currently specified: D-Bus messages, and streams of bytes. Each tube has a service name, which is a string specifying the kind of communication that takes place over it, and a dictionary of arbitrary parameters. Tube parameters are commonly used for bootstrap information such as usernames and passwords. Each tube is identified by a locally unique identifier.
The Tubes channel type may be requested for handles of type HANDLE_TYPE_CONTACT and HANDLE_TYPE_ROOM.
Stream tubes specify listening addresses using pairs of parameters with signature 'u', 'v', where the integer 'u' is a member of Socket_Address_Type and the v is dependent on the type of address.
Available_Stream_Tube_Types
−
a{uau}
(Supported_Socket_Map)A mapping from address types (members of Socket_Address_Type) to arrays of access-control type (members of Socket_Access_Control) that the connection manager supports for stream tubes with that address type. For simplicity, if a CM supports offering a particular type of tube, it is assumed to support accepting it.
A typical value for a host without IPv6 support:
{ Socket_Address_Type_IPv4: [Socket_Access_Control_Localhost, Socket_Access_Control_Port, Socket_Access_Control_Netmask], Socket_Address_Type_Unix: [Socket_Access_Control_Localhost, Socket_Access_Control_Credentials] }
If stream tubes are not supported, this will be an empty dictionary.
Available_Tube_Types
−
au
(Tube_Type[])Tubes
−
a(uuusa{sv}u)
(Tube_Info[])Service
−
s
Parameters
−
a{sv}
(String_Variant_Map)Tube_ID
−
u
(Tube_ID)org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotImplemented
Service
−
s
Parameters
−
a{sv}
(String_Variant_Map)A dictionary of properties for the new tube; the allowable keys, types and values are defined by the service. Connection managers must support the value being any primitive (non-container) D-Bus type, or a byte array 'ay'.
These should usually be the same key-value pairs specified for use in the DNS-SD TXT record for that service.
Address_Type
−
u
(Socket_Address_Type)Address
−
v
Access_Control
−
u
(Socket_Access_Control)Access_Control_Param
−
v
Tube_ID
−
u
(Tube_ID)org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotImplemented
ID
−
u
(Tube_ID)Address
−
s
org.freedesktop.Telepathy.Error.InvalidArgument
ID
−
u
(Tube_ID)Address_Type
−
u
(Socket_Address_Type)Access_Control
−
u
(Socket_Access_Control)Access_Control_Param
−
v
Address
−
v
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotImplemented
ID
−
u
(Tube_ID)org.freedesktop.Telepathy.Error.InvalidArgument
ID
−
u
(Tube_ID)Address
−
s
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
ID
−
u
(Tube_ID)DBus_Names
−
a(us)
(DBus_Tube_Member[])org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
ID
−
u
(Tube_ID)Address_Type
−
u
(Socket_Address_Type)Address
−
v
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
ID
−
u
(Tube_ID)Initiator
−
u
(Contact_Handle)Type
−
u
(Tube_Type)Service
−
s
Parameters
−
a{sv}
(String_Variant_Map)State
−
u
(Tube_State)ID
−
u
(Tube_ID)State
−
u
(Tube_State)ID
−
u
(Tube_ID)ID
−
u
(Tube_ID)Added
−
a(us)
(DBus_Tube_Member[])Removed
−
au
(Contact_Handle[])ID
−
u
(Tube_ID)Handle
−
u
(Contact_Handle)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Tube_Type_DBus = 0
The tube is D-Bus tube as described by the org.freedesktop.Telepathy.Channel.Type.DBusTube interface.
Tube_Type_Stream = 1
The tube is stream tube as described by the org.freedesktop.Telepathy.Channel.Type.StreamTube interface.
Tube_State_Local_Pending = 0
Tube_State_Remote_Pending = 1
Tube_State_Open = 2
Socket_Address_Type_Unix = 0
Socket_Address_Type_Abstract_Unix = 1
Socket_Address_Type_IPv4 = 2
Socket_Address_Type_IPv6 = 3
Socket_Access_Control_Localhost = 0
Socket_Access_Control_Port = 1
Socket_Access_Control_Netmask = 2
Socket_Access_Control_Credentials = 3
The connecting process must send a single zero (NUL) byte when it first connects, which is not considered to be part of the data stream. If the operating system uses sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over sockets, the connecting process must do so if possible; if not, it must still send the byte.
The listening process will disconnect the connection unless it can determine by OS-specific means that the connecting process has the same user ID as the listening process.
The associated variant must be ignored.
In bindings that need a separate name, arrays of Tube_Info should be called Tube_Info_List.
Identifier
−
u
(Tube_ID)Initiator
−
u
(Contact_Handle)Type
−
u
(Tube_Type)Service
−
s
Parameters
−
a{sv}
(String_Variant_Map)State
−
u
(Tube_State)In bindings that need a separate name, arrays of DBus_Tube_Member should be called DBus_Tube_Member_List.
Handle
−
u
(Contact_Handle)Unique_Name
−
s
(DBus_Unique_Name)Arrays of Socket_Address_IPv4 don't generally make sense.
Address
−
s
Port
−
q
Arrays of Socket_Address_IPv6 don't generally make sense.
Address
−
s
Port
−
q
Arrays of Socket_Netmask_IPv4 don't generally make sense.
Address
−
s
Prefix_Length
−
y
Arrays of Socket_Netmask_IPv6 don't generally make sense.
Address
−
s
Prefix_Length
−
y
Address_Type
−
u
(Socket_Address_Type)Access_Control
−
au
(Socket_Access_Control[])This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
A stream tube is a transport for ordered, reliable data transfer, similar to SOCK_STREAM sockets.
When offering a stream tube, the initiating client creates a local listening socket and offers it to the recipient client using the OfferStreamTube method. When a recipient accepts a stream tube using the AcceptStreamTube method, the recipient's connection manager creates a new local listening socket. Each time the recipient's client connects to this socket, the initiator's connection manager proxies this connection to the originally offered socket.
address_type
−
u
(Socket_Address_Type)address
−
v
access_control
−
u
(Socket_Access_Control)access_control_param
−
v
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotImplemented
address_type
−
u
(Socket_Address_Type)access_control
−
u
(Socket_Access_Control)access_control_param
−
v
address
−
v
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotImplemented
handle
−
u
(Contact_Handle)Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Service
− s
, read-onlyA string representing the service name that will be used over the tube. It should be a well-known TCP service name as defined by http://www.iana.org/assignments/port-numbers or http://www.dns-sd.org/ServiceTypes.html, for instance "rsync" or "daap".
When the tube is offered, the service name is transmitted to the other end.
When requesting a channel with Connection.Interface.Requests.CreateChannel, this property MUST be included in the request.
SupportedSocketTypes
− a{uau}
(Supported_Socket_Map), read-onlyA mapping from address types (members of Socket_Address_Type) to arrays of access-control type (members of Socket_Access_Control) that the connection manager supports for stream tubes with that address type. For simplicity, if a CM supports offering a particular type of tube, it is assumed to support accepting it.
A typical value for a host without IPv6 support:
{ Socket_Address_Type_IPv4: [Socket_Access_Control_Localhost, Socket_Access_Control_Port, Socket_Access_Control_Netmask], Socket_Address_Type_Unix: [Socket_Access_Control_Localhost, Socket_Access_Control_Credentials] }
Connection Managers MUST support at least IPv4 with the localhost access control.
When requesting a channel with Connection.Interface.Requests.CreateChannel, this property MUST NOT be included in the request.
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
A D-Bus tube is an ordered reliable transport, for transporting D-Bus traffic.
For each D-Bus tube, the connection manager listens on a D-Bus server address, as detailed in the D-Bus specification. On this address, it emulates a bus upon which each tube participant appears as an endpoint.
The objects and interfaces which are expected to exist on the emulated bus depend on the well-known name; typically, either the participant who initiated the tube is expected to export the same objects/interfaces that would be exported by a service of that name on a bus, or all participants are expected to export those objects/interfaces.
In a multi-user context (Handle_Type_Room) the tube behaves like the D-Bus bus daemon, so participants can send each other private messages, or can send broadcast messages which are received by everyone in the tube (including themselves). Each participant has a D-Bus unique name; connection managers MUST prevent participants from sending messages with the wrong sender unique name, and SHOULD attempt to avoid participants receiving messages not intended for them.
In a 1-1 context (Handle_Type_Contact) the tube behaves like a peer-to-peer D-Bus connection - arbitrary D-Bus messages with any sender and/or destination can be sent by each participant, and each participant receives all messages sent by the other participant.
address
−
s
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
address
−
s
added
−
a{us}
(DBus_Tube_Participants)removed
−
au
(Contact_Handle[])Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ServiceName
− s
, read-onlyA string representing the service name that will be used over the tube. It SHOULD be a well-known D-Bus service name, of the form com.example.ServiceName.
When the tube is offered, the service name is transmitted to the other end.
When requesting a channel with Connection.Interface.Requests.CreateChannel, this property MUST be included in the request.
DBusNames
− a{us}
(DBus_Tube_Participants), read-onlyHandle
−
u
(Contact_Handle)Unique_Name
−
s
(DBus_Unique_Name)Implementations of this interface must also implement:
A channel type for transferring files. The transmission of data between contacts is achieved by reading from or writing to a socket. The type of the socket (local Unix, IPv4, etc.) is decided on when the file transfer is offered or accepted.
A socket approach is used to make the transfer less dependent on both client and connection manager knowing the same protocols. As an example, when browsing an SMB share in a file manager, one selects "Send file" and chooses a contact. Instead of passing a URL which would then require the connection manager to connect to the SMB share itself, the client passes a stream from which the connection manager reads, requiring no further connection to the share. It also allows connection managers to be more restricted in their access to the system, allowing tighter security policies with eg SELinux, or more flexible deployments which cross user or system boundaries.
The Telepathy client should connect to the socket or address that the connection manager has set up and provided back to the clients through the two methods.
If something goes wrong with the transfer, Channel.Close should be called on the channel.
The File channel type may be requested for handles of type HANDLE_TYPE_CONTACT. If the channel is requested for any other handle type then the behaviour is undefined.
Added in version 0.17.18. (as stable API)
Address_Type
−
u
(Socket_Address_Type)Access_Control
−
u
(Socket_Access_Control)Access_Control_Param
−
v
Offset
−
t
Address
−
v
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Address_Type
−
u
(Socket_Address_Type)Access_Control
−
u
(Socket_Access_Control)Access_Control_Param
−
v
Address
−
v
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
State
−
u
(File_Transfer_State)Reason
−
u
(File_Transfer_State_Change_Reason)Count
−
t
InitialOffset
−
t
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
State
− u
(File_Transfer_State), read-onlyThe state of the file transfer as described by the File_Transfer_State enum.
ContentType
− s
, read-onlyThe file's MIME type. This cannot change once the channel has been created.
This property is mandatory when requesting the channel with the Connection.Interface.Requests.CreateChannel method. Protocols which do not have a content-type property with file transfers should set this value to application/octet-stream.
Filename
− s
, read-onlyThe name of the file on the sender's side. This is therefore given as a suggested filename for the receiver. This cannot change once the channel has been created.
This property should be the basename of the file being sent. For example, if the sender sends the file /home/user/monkey.pdf then this property should be set to monkey.pdf.
This property is mandatory when requesting the channel with the Connection.Interface.Requests.CreateChannel method. This property cannot be empty and MUST be set to a sensible value.
Size
− t
, read-onlyThe size of the file. If this property is set, then the file transfer is guaranteed to be this size. This cannot change once the channel has been created.
When you are creating a channel with this property, its value MUST be accurate and in bytes. However, when receiving a file, this property still MUST be in bytes but might not be entirely accurate to the byte.
This property is mandatory when requesting the channel with the Connection.Interface.Requests.CreateChannel method. If this information isn't provided in the protocol, connection managers MUST set it to UINT64_MAX.
ContentHashType
− u
(File_Hash_Type), read-onlyThe type of the ContentHash property.
This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method. However, if you wish to include the ContentHash property you MUST also include this property. If you omit this property from a Connection.Interface.Requests.CreateChannel method call then its value will be assumed to be File_Hash_Type_None.
ContentHash
− s
, read-onlyHash of the contents of the file transfer, of type described in the value of the ContentHashType property.
This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method. Its value MUST correspond to the appropriate type of the ContentHashType property. If the ContentHashType property is not set, or set to File_Hash_Type_None, then this property will not even be looked at.
Description
− s
, read-onlyDescription of the file transfer. This cannot change once the channel has been created.
This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method. If this property was not provided by the remote party, connection managers MUST set it to the empty string.
Date
− x
(Unix_Timestamp64), read-onlyThe last modification time of the file being transferred. This cannot change once the channel has been created
This property is optional when requesting the channel with the Connection.Interface.Requests.CreateChannel method.
AvailableSocketTypes
− a{uau}
(Supported_Socket_Map), read-onlyA mapping from address types (members of Socket_Address_Type) to arrays of access-control type (members of Socket_Access_Control) that the connection manager supports for sockets with that address type. For simplicity, if a CM supports offering a particular type of file transfer, it is assumed to support accepting it. Connection Managers MUST support at least Socket_Address_Type_IPv4.
A typical value for a host without IPv6 support:
{ Socket_Address_Type_IPv4: [Socket_Access_Control_Localhost, Socket_Access_Control_Port, Socket_Access_Control_Netmask], Socket_Address_Type_Unix: [Socket_Access_Control_Localhost, Socket_Access_Control_Credentials] }
TransferredBytes
− t
, read-onlyThe number of bytes that have been transferred at the time of requesting the property. This will be updated as the file transfer continues.
InitialOffset
− t
, read-onlyThe offset in bytes from where the file should be sent. This MUST be respected by both the receiver and the sender after the state becomes Open, but before any data is sent or received. Until the InitialOffsetDefined signal is emitted, this property is undefined.
Before setting the State property to Open, the connection manager MUST set the InitialOffset property, possibly to 0.
This property MUST NOT change after the state of the transfer has changed to Open.
File_Transfer_State_None = 0
File_Transfer_State_Pending = 1
File_Transfer_State_Accepted = 2
File_Transfer_State_Open = 3
File_Transfer_State_Completed = 4
File_Transfer_State_Cancelled = 5
File_Transfer_State_Change_Reason_None = 0
File_Transfer_State_Change_Reason_Requested = 1
File_Transfer_State_Change_Reason_Local_Stopped = 2
File_Transfer_State_Change_Reason_Remote_Stopped = 3
File_Transfer_State_Change_Reason_Local_Error = 4
File_Transfer_State_Change_Reason_Remote_Error = 5
File_Hash_Type_None = 0
File_Hash_Type_MD5 = 1
File_Hash_Type_SHA1 = 2
File_Hash_Type_SHA256 = 3
This interface is not yet API-stable and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Interface for streamed media channels that can be merged and split in the same sort of way as in GSM or PBX telephony.
Added in version 0.17.1.
Other
−
o
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Contact
−
u
(Contact_Handle)Channel
−
o
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NotAvailable
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Implementations of this interface must also implement:
An interface for streamed media channels that can indicate call 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).Added in version 0.17.2.
States
−
a{uu}
(Channel_Call_State_Map)Contact
−
u
(Contact_Handle)State
−
u
(Channel_Call_State_Flags)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Channel_Call_State_Ringing = 1
Channel_Call_State_Queued = 2
Channel_Call_State_Held = 4
Channel_Call_State_Forwarded = 8
Contact
−
u
(Contact_Handle)State
−
u
(Channel_Call_State_Flags)Implementations of this interface must also implement:
An interface for channels for receiving notifications of remote contacts' state, and for notifying remote contacts of the local state.
Clients should assume that a contact's state is Channel_Chat_State_Inactive unless they receive a notification otherwise.
The Channel_Chat_State_Gone state is treated differently to other states:
The different states are defined by XEP-0085, but may be applied to any suitable protocol.
State
−
u
(Channel_Chat_State)org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidArgument
Contact
−
u
(Contact_Handle)State
−
u
(Channel_Chat_State)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Channel_Chat_State_Gone = 0
Channel_Chat_State_Inactive = 1
Channel_Chat_State_Active = 2
Channel_Chat_State_Paused = 3
Channel_Chat_State_Composing = 4
Implementations of this interface must also implement:
This interface exists to support channels where Channel.Close is insufficiently destructive. At the moment this means Channel.Type.Text, but the existence of this interface means that unsupported channels can be terminated in a non-channel-type-specific way.
Added in version 0.17.14. (as stable API)
Close the channel abruptly, possibly with loss of data. The connection manager MUST NOT re-create the channel unless/until more events occur.
The main motivating situation for this method is that when a Text channel with pending messages is closed with Close, it comes back as an incoming channel (to avoid a race between Close and an incoming message). If Destroy is called on a Text channel, the CM should delete all pending messages and close the channel, and the channel shouldn't be re-created until/unless another message arrives.
Most clients SHOULD call Channel.Close instead. However, if a client explicitly intends to destroy the channel with possible loss of data, it SHOULD call this method if this interface is supported (according to the Channel.Interfaces property), falling back to Close if not.
In particular, channel dispatchers SHOULD use this method if available when terminating channels that cannot be handled correctly (for instance, if no handler has been installed for a channel type, or if the handler crashes repeatedly).
Connection managers do not need to implement this interface on channels where Close and Destroy would be equivalent.
Callers need to be able to fall back to Close in any case.
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Implementations of this interface must also implement:
An interface that gives a Channel the ability to send DTMF events over audio streams which have been established using the StreamedMedia channel type. The event codes used are in common with those defined in RFC4733, and are listed in the DTMF_Event enumeration.Stream_ID
−
u
(Stream_ID)Event
−
y
(DTMF_Event)org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Stream_ID
−
u
(Stream_ID)org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
DTMF_Event_Digit_0 = 0
DTMF_Event_Digit_1 = 1
DTMF_Event_Digit_2 = 2
DTMF_Event_Digit_3 = 3
DTMF_Event_Digit_4 = 4
DTMF_Event_Digit_5 = 5
DTMF_Event_Digit_6 = 6
DTMF_Event_Digit_7 = 7
DTMF_Event_Digit_8 = 8
DTMF_Event_Digit_9 = 9
DTMF_Event_Asterisk = 10
DTMF_Event_Hash = 11
DTMF_Event_Letter_A = 12
DTMF_Event_Letter_B = 13
DTMF_Event_Letter_C = 14
DTMF_Event_Letter_D = 15
Implementations of this interface must also implement:
Interface for channels which have multiple members, and where the members of the channel can change during its lifetime. Your presence in the channel cannot be presumed by the channel's existence (for example, a channel you may request membership of but your request may not be granted).
This interface implements three lists: a list of current members (Members), and two lists of local pending and remote pending members (LocalPendingMembers and RemotePendingMembers, respectively). Contacts on the remote pending list have been invited to the channel, but the remote user has not accepted the invitation. Contacts on the local pending list have requested membership of the channel, but the local user of the framework must accept their request before they may join. A single contact should never appear on more than one of the three lists. The lists are empty when the channel is created, and the MembersChanged signal (and, if the channel's GroupFlags contains Members_Changed_Detailed, the MembersChangedDetailed signal) should be emitted when information is retrieved from the server, or changes occur.
If the MembersChanged or MembersChangedDetailed signal indicates that the SelfHandle has been removed from the channel, and the channel subsequently emits Closed, clients SHOULD consider the details given in the MembersChanged or MembersChangedDetailed signal to be the reason why the channel closed.
Addition of members to the channel may be requested by using AddMembers. If remote acknowledgement is required, use of the AddMembers method will cause users to appear on the remote pending list. If no acknowledgement is required, AddMembers will add contacts to the member list directly. If a contact is awaiting authorisation on the local pending list, AddMembers will grant their membership request.
Removal of contacts from the channel may be requested by using RemoveMembers. If a contact is awaiting authorisation on the local pending list, RemoveMembers will refuse their membership request. If a contact is on the remote pending list but has not yet accepted the invitation, RemoveMembers will rescind the request if possible.
It should not be presumed that the requester of a channel implementing this interface is immediately granted membership, or indeed that they are a member at all, unless they appear in the list. They may, for instance, be placed into the remote pending list until a connection has been established or the request acknowledged remotely.
If the local user joins a Group channel whose members or other state cannot be discovered until the user joins (e.g. many chat room implementations), the connection manager should ensure that the channel is, as far as possible, in a consistent state before adding the local contact to the members set; until this happens, the local contact should be in the remote-pending set. For instance, if the connection manager queries the server to find out the initial members list for the channel, it should leave the local contact in the remote-pending set until it has finished receiving the initial members list.
If the protocol provides no reliable way to tell whether the complete initial members list has been received yet, the connection manager should make a best-effort attempt to wait for the full list (in the worst case, waiting for a suitable arbitrary timeout) rather than requiring user interfaces to do so on its behalf.
Invite all the given contacts into the channel, or accept requests for channel membership for contacts on the pending local list.
A message may be provided along with the request, which will be sent to the server if supported. See the CHANNEL_GROUP_FLAG_MESSAGE_ADD and CHANNEL_GROUP_FLAG_MESSAGE_ACCEPT GroupFlags to see in which cases this message should be provided.
Attempting to add contacts who are already members is allowed; connection managers must silently accept this, without error.
Contacts
−
au
(Contact_Handle[])Message
−
s
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.Channel.Full
org.freedesktop.Telepathy.Error.Channel.InviteOnly
org.freedesktop.Telepathy.Error.Channel.Banned
Deprecated since version 0.17.6. Use GetAll on the D-Bus Properties D-Bus interface to get properties including Members, RemotePendingMembers and LocalPendingMembers instead, falling back to this method and GetLocalPendingMembersWithInfo if necessary.
Members
−
au
(Contact_Handle[])Local_Pending
−
au
(Contact_Handle[])Remote_Pending
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Deprecated since version 0.17.6. Use GetAll on the D-Bus Properties D-Bus interface to get properties including GroupFlags instead, falling back to this method if necessary.
Group_Flags
−
u
(Channel_Group_Flags)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Deprecated since version 0.17.6. Clients should use the HandleOwners property and HandleOwnersChanged signal if Channel_Group_Flag_Properties is present.
Handles
−
au
(Contact_Handle[])Owners
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.InvalidArgument
Deprecated since version 0.17.6. Use the LocalPendingMembers property, if Channel_Group_Flag_Properties is present.
Handles
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Added in version 0.15.0.
Deprecated since version 0.17.6. Use the LocalPendingMembers property, if Channel_Group_Flag_Properties is present.
Info
−
a(uuus)
(Local_Pending_Info[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Deprecated since version 0.17.6. Use the Members property, if Channel_Group_Flag_Properties is present.
Handles
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Deprecated since version 0.17.6. Use the RemotePendingMembers property, if Channel_Group_Flag_Properties is present.
Handles
−
au
(Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Deprecated since version 0.17.6. Clients should retrieve the SelfHandle property using GetAll instead, if Channel_Group_Flag_Properties is present.
Self_Handle
−
u
(Contact_Handle)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Contacts
−
au
(Contact_Handle[])Message
−
s
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.InvalidHandle
Contacts
−
au
(Contact_Handle[])Message
−
s
Reason
−
u
(Channel_Group_Change_Reason)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.InvalidHandle
org.freedesktop.Telepathy.Error.InvalidArgument
Added in version 0.17.6. This signal should not be relied on unless Channel_Group_Flag_Properties is present.
Added
−
a{uu}
(Handle_Owner_Map)Removed
−
au
(Contact_Handle[])Added in version 0.17.6. This signal should not be relied on unless Channel_Group_Flag_Properties is present.
Self_Handle
−
u
(Contact_Handle)Added
−
u
(Channel_Group_Flags)Removed
−
u
(Channel_Group_Flags)Emitted when contacts join any of the three lists (members, local pending or remote pending) or when they leave any of the three lists. There may also be a message from the server regarding this change, which may be displayed to the user if desired.
All channel-specific handles that are mentioned in this signal MUST be represented in the value of the HandleOwners property. In practice, this will mean that HandleOwnersChanged is emitted before emitting a MembersChanged signal in which channel-specific handles are added, but that it is emitted after emitting a MembersChanged signal in which channel-specific handles are removed.
Message
−
s
Added
−
au
(Contact_Handle[])Removed
−
au
(Contact_Handle[])Local_Pending
−
au
(Contact_Handle[])Remote_Pending
−
au
(Contact_Handle[])Actor
−
u
(Contact_Handle)Reason
−
u
(Channel_Group_Change_Reason)Emitted when contacts join any of the three lists (members, local pending or remote pending) or when they leave any of the three lists. This signal provides a superset of the information provided by MembersChanged; if the channel's GroupFlags contains Members_Changed_Detailed, then clients may listen exclusively to this signal in preference to that signal.
All channel-specific handles that are mentioned in this signal MUST be represented in the value of the HandleOwners property. In practice, this will mean that HandleOwnersChanged is emitted before emitting a MembersChangedDetailed signal in which channel-specific handles are added, but that it is emitted after emitting a MembersChangedDetailed signal in which channel-specific handles are removed.
Added in version 0.17.16.
Added
−
au
(Contact_Handle[])Removed
−
au
(Contact_Handle[])Local_Pending
−
au
(Contact_Handle[])Remote_Pending
−
au
(Contact_Handle[])Details
−
a{sv}
(String_Variant_Map)Information about the change, which may include the following well-known keys:
The string identifiers for handles mentioned in this signal, to give clients the minimal information necessary to react to the event without waiting for round-trips. Connection managers SHOULD include the identifiers for members added to the group and for the actor (if any); they MAY omit the identifiers for handles which have been removed from the group.
On IRC, an event such as a netsplit could cause the vast majority of a channel to leave. Given that clients should already know the identifiers of a channel's members, including potentially hundreds of strings in the netsplit signal is unnecessary.
Clients MUST NOT assume that the presence or absence of a handle in this mapping is meaningful. This mapping is merely an optimization for round-trip reduction, and connection managers MAY add additional handles, omit some handles, or omit the mapping completely.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
GroupFlags
− u
(Channel_Group_Flags), read-onlyAdded in version 0.17.6. For backwards compatibility, clients should fall back to calling GetGroupFlags if Channel_Group_Flag_Properties is not present.
HandleOwners
− a{uu}
(Handle_Owner_Map), read-onlyAdded in version 0.17.6.
LocalPendingMembers
− a(uuus)
(Local_Pending_Info[]), read-onlyAdded in version 0.17.6. If Channel_Group_Flag_Properties is not present, clients should fall back to using the deprecated GetLocalPendingMembersWithInfo method, or fall back from that to the deprecated GetAllMembers method.
Members
− au
(Contact_Handle[]), read-onlyAdded in version 0.17.6. If Channel_Group_Flag_Properties is not set, fall back to calling GetAllMembers.
RemotePendingMembers
− au
(Contact_Handle[]), read-onlyAdded in version 0.17.6. If Channel_Group_Flag_Properties is not set, fall back to calling GetAllMembers.
SelfHandle
− u
(Contact_Handle), read-onlyAdded in version 0.17.6. For backwards compatibility, clients should fall back to calling GetSelfHandle if Channel_Group_Flag_Properties is not present.
Channel_Group_Change_Reason_None = 0
Channel_Group_Change_Reason_Offline = 1
The change is due to a user going offline. Also used when user is already offline, but this wasn't known previously.
If a one-to-one StreamedMedia call fails because the contact being called is offline, the connection manager SHOULD indicate this by removing both the SelfHandle and the other contact's handle from the Group interface with reason Offline.
If a handle is removed from a group for this reason, the
equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Offline
.
Channel_Group_Change_Reason_Kicked = 2
The change is due to a kick operation.
If the SelfHandle is removed
from a group for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Channel.Kicked
.
Channel_Group_Change_Reason_Busy = 3
The change is due to a busy indication.
If a one-to-one StreamedMedia call fails because the contact being called is busy, the connection manager SHOULD indicate this by removing both the SelfHandle and the other contact's handle from the Group interface with reason Busy.
If the SelfHandle is removed
from a group for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Busy
.
Channel_Group_Change_Reason_Invited = 4
Channel_Group_Change_Reason_Banned = 5
The change is due to a kick+ban operation.
If the SelfHandle is removed
from a group for this reason, the equivalent D-Bus error is
org.freedesktop.Telepathy.Error.Channel.Banned
.
Channel_Group_Change_Reason_Error = 6
Channel_Group_Change_Reason_Invalid_Contact = 7
The change is because the requested contact does not exist.
For instance, if the user invites a nonexistent contact to a chatroom or attempts to call a nonexistent contact, this could be indicated by the CM adding that contact's handle to remote-pending for reason None or Invited, then removing it for reason Invalid_Contact. In the case of a 1-1 StreamedMedia call, the CM SHOULD remove the self handle from the Group in the same signal.
If a contact is removed from a group for this reason, the
equivalent D-Bus error is
org.freedesktop.Telepathy.Error.DoesNotExist
.
Channel_Group_Change_Reason_No_Answer = 8
The change is because the requested contact did not respond.
If a one-to-one StreamedMedia call fails because the contact being called did not respond, the connection manager SHOULD indicate this by removing both the SelfHandle and the other contact's handle from the Group interface with reason No_Answer.
If a contact is removed from a group for this reason, the
equivalent D-Bus error is
org.freedesktop.Telepathy.Error.NoAnswer
.
Channel_Group_Change_Reason_Renamed = 9
The change is because a contact's unique identifier changed. There must be exactly one handle in the removed set and exactly one handle in one of the added sets. The Renamed signal on the Renaming interface will have been emitted for the same handles, shortly before this MembersChanged signal is emitted.
Channel_Group_Change_Reason_Permission_Denied = 10
The change is because there was no permission to contact the requested handle.
If a contact is removed from a group for this reason, the
equivalent D-Bus error is
org.freedesktop.Telepathy.Error.PermissionDenied
.
Channel_Group_Change_Reason_Separated = 11
If members are removed with this reason code, the change is because the group has split into unconnected parts which can only communicate within themselves (e.g. netsplits on IRC use this reason code).
If members are added with this reason code, the change is because unconnected parts of the group have rejoined. If this channel carries messages (e.g. Text or Tubes channels) applications must assume that the contacts being added are likely to have missed some messages as a result of the separation, and that the contacts in the group are likely to have missed some messages from the contacts being added.
Note that from the added contacts' perspective, they have been in the group all along, and the contacts we indicate to be in the group (including the local user) have just rejoined the group with reason Separated. Application protocols in Tubes should be prepared to cope with this situation.
The SelfHandle SHOULD NOT be removed from channels with this reason.
Channel_Group_Flag_Can_Add = 1
Channel_Group_Flag_Can_Remove = 2
Channel_Group_Flag_Can_Rescind = 4
Channel_Group_Flag_Message_Add = 8
Channel_Group_Flag_Message_Remove = 16
Channel_Group_Flag_Message_Accept = 32
Channel_Group_Flag_Message_Reject = 64
Channel_Group_Flag_Message_Rescind = 128
Channel_Group_Flag_Channel_Specific_Handles = 256
The members of this group have handles which are specific to this channel, and are not valid as general-purpose handles on the connection. Depending on the channel, it may be possible to check the HandleOwners property or call GetHandleOwners to find the owners of these handles, which should be done if you wish to (e.g.) subscribe to the contact's presence.
Connection managers must ensure that any given handle is not simultaneously a general-purpose handle and a channel-specific handle.
Channel_Group_Flag_Only_One_Group = 512
Channel_Group_Flag_Handle_Owners_Not_Available = 1024
Channel_Group_Flag_Properties = 2048
Channel_Group_Flag_Members_Changed_Detailed = 4096
In bindings that need a separate name, arrays of Local_Pending_Info should be called Local_Pending_Info_List.
To_Be_Added
−
u
(Contact_Handle)Actor
−
u
(Contact_Handle)Reason
−
u
(Channel_Group_Change_Reason)Message
−
s
Channel_Specific_Handle
−
u
(Contact_Handle)Global_Handle
−
u
(Contact_Handle)Handle
−
u
(Contact_Handle)Identifier
−
s
Implementations of this interface must also implement:
Interface for channels where you may put the channel on hold. This only makes sense for channels where you are streaming media to or from the members.
If you place a channel on hold, this indicates that you do not wish to be sent media streams by any of its members and will be ignoring any media streams you continue to receive. It also requests that the connection manager free up any resources that are only needed for an actively used channel (e.g. in a GSM or PBX call, it will be necessary to place an active call on hold before you can start another call).
Changed in version 0.17.4: first API-stable version
HoldState
−
u
(Local_Hold_State)Reason
−
u
(Local_Hold_State_Reason)Request that the channel be put on hold (be instructed not to send any media streams to you) or be taken off hold.
If the connection manager can immediately tell that the requested state change could not possibly succeed, this method SHOULD return the NotAvailable error. If the requested state is the same as the current state, this method SHOULD return successfully without doing anything.
Otherwise, this method SHOULD immediately set the hold state to Local_Hold_State_Pending_Hold or Local_Hold_State_Pending_Unhold (as appropriate), emitting HoldStateChanged if this is a change, and return successfully.
The eventual success or failure of the request is indicated by a subsequent HoldStateChanged signal, changing the hold state to Local_Hold_State_Held or Local_Hold_State_Unheld.
If the channel has multiple streams, and the connection manager succeeds in changing the hold state of one stream but fails to change the hold state of another, it SHOULD attempt to revert all streams to their previous hold states.
The following state transitions SHOULD be used, where appropriate:
Hold
−
b
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.NotAvailable
HoldState
−
u
(Local_Hold_State)Reason
−
u
(Local_Hold_State_Reason)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Local_Hold_State_Unheld = 0
Local_Hold_State_Held = 1
Local_Hold_State_Pending_Hold = 2
Local_Hold_State_Pending_Unhold = 3
Local_Hold_State_Reason_None = 0
Local_Hold_State_Reason_Requested = 1
Local_Hold_State_Reason_Resource_Not_Available = 2
This interface is unfinished and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
This interface extends the Messages interface to support capability discovery, so clients can decide what subset of HTML is supported.
(However, the capability discovery mechanism has not been written yet, so this interface MUST NOT be used. It exists only to indicate what direction we intend to go in.)
XMPP supports all of XHTML-IM, and SIP (at least theoretically) supports all of XHTML. However, many protocols are more limited - for instance, in MSN you can only set font properties for a whole message at a time. We should not mislead users into thinking they can send MSN messages where individual words are emphasized.
If this interface is present, clients MAY send XHTML formatted text in message parts with type "text/html", and SHOULD interpret "text/html" message parts received in reply.
Client authors SHOULD pay careful attention to the security considerations in XEP-0071, "XHTML-IM", to avoid exposing client users to security risks. Clients MUST NOT assume that connection managers will filter messages to remove unsafe HTML.
Connection managers are the components in Telepathy that are most likely to be exploitable by a remote attacker to run malicious code (since they are network-facing), so any filtering that the CM does might be subverted.
To avoid misleading users, clients SHOULD only present UI for the subset of HTML that is indicated to be supported by this interface. It follows that clients SHOULD NOT send unsupported markup to the connection manager. However, even if the connection manager cannot send arbitrary XHTML, it MUST cope gracefully with being given arbitrary XHTML by a client.
Connection managers should be lenient in what they receive.
Clients MUST NOT send HTML that is not well-formed XML, but connection managers MAY signal HTML that is malformed or invalid. Clients SHOULD attempt to parse messages as XHTML, but fall back to using a permissive "tag-soup" HTML parser if that fails. (FIXME: or should the presence of this interface imply that the CM fixes up "text/html" to be XHTML? In practice that would result in all the CMs having to link against libxml2 or something... the rationale above no longer applies here, since dropping a malformed message is "safe")
Added in version 0.17.5. (draft version, not API-stable)
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Implementations of this interface must also implement:
Interface for channels that may have a password set that users need to provide before being able to join, or may be able to view or change once they have joined the channel.
The GetPasswordFlags method and the associated PasswordFlagsChanged signal indicate whether the channel has a password, whether the user must now provide it to join, and whether it can be viewed or changed by the user.
Password_Flags
−
u
(Channel_Password_Flags)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
Password
−
s
Correct
−
b
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.InvalidArgument
Added
−
u
(Channel_Password_Flags)Removed
−
u
(Channel_Password_Flags)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Channel_Password_Flag_Provide = 8
Implementations of this interface must also implement:
An interface for signalling a channel containing synchronised media sessions which can contain an arbitrary number of streams. The presence of this interface on a Channel indicates that the connection manager will not carry out the actual streaming for this channel, and that the client handling the channel is responsible for doing so; in most cases we recommend doing this by using the telepathy-farsight library.
Streaming audio and (particularly) video requires a high level of integration with the UI, and having the connection manager act as a proxy would be likely to introduce unacceptable latency. As a result, audio/video streaming is offloaded into the client where possible, as an exception to the general design of Telepathy.
The negotiation interface is based on the API of the Farsight library. This, in turn, is based upon the IETF MMusic ICE drafts, where connections are established by signalling potential connection candidates to the peer until a usable connection is found, and codecs are negotiated with an SDP-style offer and answer. However, the principles should be applicable to other media streaming methods and the API re-used without difficulty.
Note that the naming conventions used in the MediaStreamHandler and MediaSessionHandler interfaces are rather confusing; methods have signal-like names and signals have method-like names, due to the API being based rather too closely on that of Farsight. This is for historical reasons and will be fixed in a future release of the Telepathy specification.
Session_Handlers
−
a(os)
(Media_Session_Handler_Info[])Session_Handler
−
o
Session_Type
−
s
(Media_Session_Type)Accessed using the Telepathy Properties interface.
nat-traversal
−
s
A string indicating the NAT traversal techniques employed by the streams within this channel. Can be protocol-specific values, but the following values should be used if appropriate:
stun-server
−
s
stun-port
−
q
gtalk-p2p-relay-token
−
s
Interface has no D-Bus core properties.
In bindings that need a separate name, arrays of Media_Session_Handler_Info should be called Media_Session_Handler_Info_List.
Session_Handler
−
o
Media_Session_Type
−
s
(Media_Session_Type)Implementations of this interface must also implement:
org.freedesktop.Telepathy.Channel
org.freedesktop.Telepathy.Channel.Type.StreamedMedia
org.freedesktop.Telepathy.Channel.Type.MediaSignalling
This interface contains functionality which we intend to incorporate into the Channel.Interface.MediaSignalling interface in future. It should be considered to be conceptually part of the core MediaSignalling interface, but without API or ABI guarantees.
The rationale is the same as for Channel.FUTURE.
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ICETransportAvailable
− b
, read-onlyTrue if this channel supports the use of the ICE-UDP transport (XEP-0176, ICE RFC draft). Various other transports have boolean properties that work in the same way as this one, so this description covers all such transports.
This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. NewChannels signals.
Connection managers capable of signalling streamed media calls to contacts SHOULD include the properties representing all supported transports in the allowed properties list of the channel class in RequestableChannelClasses that advertises support for streamed media channels.
Similarly, connection managers that support the ContactCapabilities.DRAFT interface SHOULD include all supported transports in the allowed properties list of the channel class that advertises a contact's ability to receive streamed media calls.
Clients that are able to receive calls with particular NAT traversal mechanisms MAY include the following filters if calling SetSelfCapabilities (clients of a ChannelDispatcher.DRAFT SHOULD instead arrange for the ChannelDispatcher to do this, by including the filters in their HandlerChannelFilter properties):
Connection managers MAY use this information to adjust the transports for which they advertise support to other contacts. If a client has indicated support for any particular transports, the connection manager SHOULD advertise support for each transport that is supported by any client, and also supported by the CM itself.
This minimizes the possibility that a call will be started that cannot in fact succeed, because the intersection of the contacts' available transports is empty.
If no client has mentioned any of the transports known to the connection manager in a call to SetSelfCapabilities, the connection manager SHOULD advertise support for every transport that it can signal.
This simplifies implementation on integrated platforms like Maemo, where it can be assumed that client libraries will support all the "standard" transports known to any connection manager, and lowers the "barrier to entry" for new Telepathy clients.
Clients making outgoing calls for which the same client that made
the request will handle the streaming MAY indicate their ability or
inability to handle particular transports by including
ICETransportAvailable = true
,
RawUDPTransportAvailable = false
, etc.
in the request properties parameter of their call to EnsureChannel
or similar functions. When they do so, the connection manager
SHOULD attempt to use a transport that the client has indicated
it is able to handle; if this is not possible, the connection
manager SHOULD raise an error instead of creating a channel.
This enables such clients to restrict the CM to the subset of transports supported by that particular client.
Clients making outgoing calls for which they will not themselves handle the streaming (e.g. an address book starting a call which will be streamed by a separate call UI) SHOULD NOT include those properties in the request.
In general, such a client can't know the capabilities of the streaming implementation, or even which streaming implementation will be used.
In the absence of any indication of supported transports from the client, the connection manager SHOULD assume that the transports indicated by calling SetSelfCapabilities are available. If no transports were indicated as supported by calling SetSelfCapabilities either, it SHOULD assume that any transport that it can signal will be acceptable.
If this property, or any of the similar transport availability properties, is passed to EnsureChannel (as opposed to CreateChannel), the connection manager SHOULD ignore these properties when checking whether it can return an existing channel as suitable; these properties only become significant when the connection manager has decided to create a new channel.
RawUDPTransportAvailable
− b
, read-onlyThe same as ICETransportAvailable, but for raw UDP streaming as described by XEP-0177.
GoogleP2PTransportAvailable
− b
, read-onlyThe same as ICETransportAvailable, but for the variant of ICE used by the Google Talk peer-to-peer connectivity establishment mechanism (as implemented in libjingle 0.3).
MSNTransportAvailable
− b
, read-onlyThe same as ICETransportAvailable, but for the variant of ICE used by MSN.
Implementations of this interface must also implement:
This interface extends the Text interface to support more general messages, including:
Although this specification supports formatted (rich-text) messages with unformatted alternatives, implementations SHOULD NOT attempt to send formatted messages until the Telepathy specification has also been extended to cover capability discovery for message formatting.
This interface also replaces Text.SendError, adding support for protocols where the message content is not echoed back to the sender on failure, adding support for receiving positive acknowledgements, and using the Messages queue for state-recovery (ensuring that incoming delivery reports are not lost if there is not currently a process handling them).
If this interface is present, clients that support it SHOULD listen for the MessageSent and MessageReceived signals, and ignore the Sent, SendError and Received signals on the Text interface (which are guaranteed to duplicate signals from this interface).
Added in version 0.17.16. (as stable API)
Submit a message to the server for sending. If this method returns successfully, the message has been submitted to the server and the MessageSent signal is emitted. A corresponding Sent signal on the Text interface MUST also be emitted.
This method MUST return before the MessageSent signal is emitted.
This means that the process sending the message is the first to see the Sent_Message_Token, and can relate the message to the corresponding MessageSent signal by comparing message tokens (if supported by the protocol).
If this method fails, message submission to the server has failed and no signal on this interface (or the Text interface) is emitted.
Message
−
aa{sv}
(Message_Part[])Flags
−
u
(Message_Sending_Flags)Token
−
s
(Sent_Message_Token)org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NetworkError
Message_ID
−
u
(Message_ID)Parts
−
au
(Message_Part_Index[])Content
−
a{uv}
(Message_Part_Content_Map)The content of the requested parts. The keys in this mapping are positions in the array of message parts; the values are either of type 's' or 'ay' (UTF-8 text string, or byte array), following the same rules as for the value of the 'content' key in the Message_Part mappings.
If the one of the requested part numbers was greater than zero but referred to a part that had no content (i.e. it had no 'content-type' key or no 'content' key), it is simply omitted from this mapping; this is not considered to be an error condition.
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NetworkError
Signals that a message has been submitted for sending. This MUST be emitted exactly once per emission of the Sent signal on the Text interface.
This signal allows a process that is not the caller of SendMessage to log sent messages. The double signal-emission provides compatibility with older clients. Clients supporting Messages should listen for Messages.MessageSent only (if the channel has the Messages interface) or Text.Sent only (otherwise).
Content
−
aa{sv}
(Message_Part[])The message content (see Message_Part for full details). If the message that was passed to SendMessage has a formatted text part that the connection manager recognises, but no text/plain alternative, the CM MUST use the formatted text part to generate a text/plain alternative which is also included in this signal argument.
If the connection manager can predict that the message will be altered during transmission, this argument SHOULD reflect what other contacts will receive, rather than being a copy of the argument to SendMessage (if the message is truncated, formatting or alternatives are dropped, etc., then the edited version SHOULD appear in this signal).
Flags
−
u
(Message_Sending_Flags)Message_Token
−
s
(Sent_Message_Token)Message_IDs
−
au
(Message_ID[])Message
−
aa{sv}
(Message_Part[])Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
SupportedContentTypes
− as
, read-onlyA list of MIME types supported by this channel, with more preferred MIME types appearing earlier in the list. The list MAY include "*/*" to indicate that attachments with arbitrary MIME types can be sent. This list MUST NOT be empty, since all Messages implementations MUST accept messages containing a single "text/plain" part.
Some examples of how this property interacts with the MessagePartSupportFlags:
MessagePartSupportFlags
− u
(Message_Part_Support_Flags), read-onlyPendingMessages
− aaa{sv}
(Message_Part[][]), read-onlyDeliveryReportingSupport
− u
(Delivery_Reporting_Support_Flags), read-onlyAdded in version 0.17.17.
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.
CM implementations SHOULD use an identifier expected to be unique, such as a UUID, if possible.
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.
Delivery_Status_Unknown = 0
Delivery_Status_Delivered = 1
Delivery_Status_Temporarily_Failed = 2
Delivery_Status_Permanently_Failed = 3
Delivery_Status_Accepted = 4
Flags indicating the level of support for message parts on this channel. They are designed such that setting more flags always implies that the channel has more capabilities.
If no flags are set, this indicates that messages may contain a single message part whose content-type is any of the types from SupportedContentTypes, possibly with some alternatives.
There is no flag indicating support for alternatives. This is because the SendMessage implementation can always accept messages containing alternatives, even if the underlying protocol does not, by deleting all alternatives except the first (most preferred) that is supported.
See SupportedContentTypes for some examples.
Message_Part_Support_Flag_One_Attachment = 1
Message_Part_Support_Flag_Multiple_Attachments = 2
Message_Sending_Flag_Report_Delivery = 1
Provide a successful delivery report if possible, even if this is not the default for this protocol. Ignored if delivery reports are not possible on this protocol.
In some protocols, like XMPP, it is not conventional to request or send positive delivery notifications.
Delivery failure reports SHOULD always be sent, but if this flag is present, the connection manager MAY also try harder to obtain failed delivery reports or allow them to be matched to outgoing messages.
Delivery_Reporting_Support_Flag_Receive_Failures = 1
Delivery_Reporting_Support_Flag_Receive_Successes = 2
Part of a message's content. In practice, this mapping never appears in isolation - messages are represented by a list of Message_Part mappings.
An example of how a message might look, in a Python-like syntax:
[ { '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, }, { 'alternative': 'main', 'content-type': 'text/html', 'content': 'Here is a photo of my cat:<br />' + '<img src="cid:catphoto" alt="lol!" />' + '<br />Isn't it cute?', }, { 'alternative': 'main', 'content-type': 'text/plain', 'content': 'Here is a photo of my cat:\n[IMG: lol!]\nIsn't it cute?', }, { 'identifier': 'catphoto', 'content-type': 'image/jpeg', 'size': 101000, 'needs-retrieval': True, }, ]
The first part of the message contains "headers" which refer to the entire message.
It is an error for a connection manager to put keys referring to the message as a whole in the second or subsequent Message_Part, but clients MUST recover from this error by ignoring these keys in the second and subsequent parts.
Instead of representing messages as aa{sv} where the first dictionary is special (a dictionary of headers), we could have used a signature like (a{sv}aa{sv}) to separate out the headers and the body parts.
However, this would make access to the messages more awkward.
In Python, the syntax for access to a header field would remain
message[0]['message-type']
, but access to a body
field in the second body part would change from
message[2]['content'] to message[1][1]['content']. In GLib,
the message would change from being a
GPtrArray(GHashTable) to being a
GValueArray(GHashTable, GPtrArray(GHashTable)) which is rather
inconvenient to dereference.
Well-known keys for the message as a whole, and the corresponding value types, include:
The second and subsequent parts contain the message's content, including plain text, formatted text and/or attached files.
It is an error for a connection manager to put keys referring to the message body in the first Message_Part; clients MUST recover from this error by ignoring these keys in first part.
In any group of parts with the same non-empty value for the "alternative" key (which represent alternative versions of the same content), more faithful versions of the intended message MUST come before less faithful versions (note that this order is the opposite of MIME "multipart/alternative" parts). Clients SHOULD display the first alternative that they understand.
Specifying the preference order means that if the underlying protocol doesn't support alternatives, the CM can safely delete everything apart from the first supported alternative when sending messages.
The order is the reverse of MIME because MIME's rationale for placing the "plainest" part first (legibility in pre-MIME UAs) does not apply to us, and placing the most preferred part first simplifies display (a client can iterate the message in order, display the first alternative that it understands, and skip displaying all subsequent parts with the same "alternative" key).
Clients SHOULD present all parts that are not redundant alternatives in the order they appear in this array, possibly excluding parts that are referenced by another displayed part. It is implementation-specific how the parts are presented to the user.
This allows CMs to assume that all parts are actually shown to the user, even if they are not explicitly referenced - we do not yet recommend formatted text, and there is no way for plain text to reference an attachment since it has no concept of markup or references. This also forces clients to do something sensible with messages that consist entirely of "attachments", with no "body" at all.
For instance, when displaying the above example, a client that understands the HTML part should display the JPEG image once, between the two lines "Here is a photo of my cat:" and "Isn't it cute?"; it may additionally present the image in some way for a second time, after "Isn't it cute?", or may choose not to.
A client that does not understand HTML, displaying the same message, should display the plain-text part, followed by the JPEG image.
Well-known keys for the second and subsequent parts, and the corresponding value types, include:
If present, this part of the message is an alternative for all other parts with the same value for "alternative". Clients SHOULD only display one of them (this is expected to be used for XHTML messages in a future version of this specification).
If omitted, this part is not an alternative for any other part.
Parts of a message MAY reference the group of alternatives as a whole (i.e. a reference to whichever of them is chosen) by treating this identifier as if it were the MIME Content-ID of a multipart/alternative part, and using the cid: URI scheme.
The MIME type of this part. See the documentation for ReceivedMessage for notes on the special status of "text/plain" parts.
Connection managers MUST NOT signal parts without a 'content-type' key; if a protocol provides no way to determine the MIME type, the connection manager is responsible for guessing it, but MAY fall back to "text/plain" for text and "application/octet-stream" for non-text.
Clients MUST ignore parts without a 'content-type' key, which are reserved for future expansion.
Delivery reports are also represented as messages, of type Channel_Text_Message_Type_Delivery_Report, with the Non_Text_Content flag in the Text interface.
Whenever a message of type Channel_Text_Message_Type_Delivery_Report is signalled for a delivery error report, Channel.Type.Text.SendError SHOULD also be emitted; whenever Channel.Type.Text.SendError is emitted by a channel which supports this interface, a message of type Channel_Text_Message_Type_Delivery_Report MUST also be emitted.
The corresponding message in the Messages interface MUST contain "headers" for the delivery report, as specified below, in its first Message_Part.
An identifier for the message to which this delivery report refers. MUST NOT be an empty string. Omitted if not available.
Clients may match this against the token produced by the SendMessage method and MessageSent signal. A status report with no token could match any sent message, and a sent message with an empty token could match any status report. If multiple sent messages match, clients SHOULD use some reasonable heuristic.
The message content, as defined by the Messages interface. Omitted if no content is available. Content MAY have been truncated, message parts MAY have been removed, and message parts MAY have had their content removed (i.e. the message part metadata is present, but the 'content' key is not).
Unlike in the Messages interface, content not visible in the value for this key cannot be retrieved by another means, so the connection manager SHOULD be more aggressive about including (possibly truncated) message content in the 'content' key.
The second and subsequent Message_Part dictionaries, if present, are a human-readable report from the IM service.
Clients MUST NOT attempt to send delivery reports using the SendMessage method in the Messages API, and connection managers MUST NOT allow this to be done. If support for sending delivery reports is later added, it will be part of this interface.
Some example delivery reports in a Python-like syntax (in which arrays are indicated by [a, b] and dictionaries by {k1: v1, k2: v2}) follow.
b9a991bd-8845-4d7f-a704-215186f43bb4
for an unknown
reason[{ # header 'message-sender': 123, 'message-type': Channel_Text_Message_Type_Delivery_Report, 'delivery-status': Delivery_Status_Permanently_Failed, 'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4', } # no body ]
[{ # header 'message-sender': 123, 'message-type': Channel_Text_Message_Type_Delivery_Report, 'delivery-status': Delivery_Status_Temporarily_Failed, 'delivery-error': Channel_Text_Send_Error_Offline, 'delivery-echo': [{ # header of original message 'message-sender': 1, 'message-sent': 1210067943, }, { # body of original message 'content-type': 'text/plain', 'content': 'Hello, world!', }] ], # no body ]
b9a991bd-8845-4d7f-a704-215186f43bb4
to a contact
with handle 123, but that handle represents a contact who does not
actually exist[{ # header 'message-sender': 123, 'message-type': Channel_Text_Message_Type_Delivery_Report, 'delivery-status': Delivery_Status_Permanently_Failed, 'delivery-error': Channel_Text_Send_Error_Invalid_Contact, 'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4', 'delivery-echo': [{ # header of original message 'message-sender': 1, 'message-sent': 1210067943, }, { # body of original message 'content-type': 'text/plain', 'content': 'Hello, world!', }] ], }, { # message from server (alternative in English) 'alternative': '404', 'content-type': 'text/plain', 'lang': 'en', 'content': 'I have no contact with that name', }, { # message from server (alternative in German) 'alternative': '404'. 'content-type': 'text/plain', 'lang': 'de', 'content', 'Ich habe keinen Kontakt mit diesem Namen', } ]
b9a991bd-8845-4d7f-a704-215186f43bb4
[{ # header 'message-sender': 123, 'message-type': Channel_Text_Message_Type_Delivery_Report, 'delivery-status': Delivery_Status_Delivered, 'delivery-token': 'b9a991bd-8845-4d7f-a704-215186f43bb4', } # no body ]
In bindings that need a separate name, arrays of Message_Part should be called Message_Part_List.
Key
−
s
Value
−
v
Part
−
u
(Message_Part_Index)Content
−
v
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
A tube is a mechanism for arbitrary data transfer between two or more IM users, used to allow applications on the users' systems to communicate without having to establish network connections themselves. Currently, two types of tube exist: Channel.Type.DBusTube and Channel.Type.StreamTube. This interface contains the properties, signals and methods common to both types of tube; you can only create channels of a specific tube type, not of this type. A tube channel contains exactly one tube; if you need several tubes, you have to create several tube channels.
Tube channels can be requested for handles of type HANDLE_TYPE_CONTACT (for 1-1 communication) or of type HANDLE_TYPE_ROOM (to communicate with others in the room simultaneously).
Interface has no methods.
state
−
u
(Tube_Channel_State)Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Parameters
− a{sv}
(String_Variant_Map), read/writeEach tube has a dictionary of arbitrary parameters. Parameters are commonly used to bootstrap legacy protocols where you can't negotiate parameters in-band. The allowable keys, types and values are defined by the service. Connection managers must support the value being a string (D-Bus type 's'), array of bytes (D-Bus type 'ay'), unsigned integer (D-Bus type 'u'), integer (D-Bus type 'i') and boolean (D-Bus type 'b').
When the tube is offered, the parameters are transmitted with the offer and appear as a property of the incoming tube for other participants.
Example of valid parameters for 'smb' Server Message Block over
TCP/IP (from DNS
SRV (RFC 2782) Service Types
http://www.dns-sd.org/ServiceTypes.html):
{'u': 'username', 'p': 'password', 'path': 'path'}
When requesting a channel with Connection.Interface.Requests.CreateChannel, this property MAY be included in the request. If it is not included in the request, the connection manager MUST consider the property to be empty. This property MAY be changed after the channel creation when the tube is in the state Not_Offered. If the tube is in another state, changing this property MUST fail without side effects.
State
− u
(Tube_Channel_State), read-onlyState of the tube in this channel.
When requesting a channel with Connection.Interface.Requests.CreateChannel, this property MUST NOT be included in the request.
Tube_Channel_State_Local_Pending = 0
Tube_Channel_State_Remote_Pending = 1
Tube_Channel_State_Open = 2
Tube_Channel_State_Not_Offered = 3
Error_Code
−
u
(Media_Stream_Error)Message
−
s
Stream_Handler
−
o
ID
−
u
Media_Type
−
u
(Media_Stream_Type)Direction
−
u
(Media_Stream_Direction)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Codec_ID
−
u
Error_Code
−
u
(Media_Stream_Error)Message
−
s
Native_Candidate_ID
−
s
Remote_Candidate_ID
−
s
Candidate_ID
−
s
Transports
−
a(usuussduss)
(Media_Stream_Handler_Transport[])Codecs
−
a(usuuua{ss})
(Media_Stream_Handler_Codec[])Used to provide codecs after Ready(), so the media client can go ready for an incoming call and exchange candidates/codecs before knowing what local codecs are available.
This is useful for gatewaying calls between two connection managers. Given an incoming call, you need to call Ready to get the remote codecs before you can use them as the "local" codecs to place the outgoing call, and hence receive the outgoing call's remote codecs to use as the incoming call's "local" codecs.
In this situation, you would pass an empty list of codecs to the incoming call's Ready method, then later call SetLocalCodecs on the incoming call in order to respond to the offer.
Codecs
−
a(usuuua{ss})
(Media_Stream_Handler_Codec[])State
−
u
(Media_Stream_State)Codecs
−
a(usuuua{ss})
(Media_Stream_Handler_Codec[])Codecs
−
a(usuuua{ss})
(Media_Stream_Handler_Codec[])Added in version 0.17.3.
Held
−
b
Added in version 0.17.3.
Candidate_ID
−
s
Transports
−
a(usuussduss)
(Media_Stream_Handler_Transport[])Deprecated since version . There is no case where you want to release candidates (except for an ICE reset, and there you'd want to replace then all, using SetRemoteCandidateList).
Candidate_ID
−
s
Native_Candidate_ID
−
s
Remote_Candidate_ID
−
s
Remote_Candidates
−
a(sa(usuussduss))
(Media_Stream_Handler_Candidate[])Codecs
−
a(usuuua{ss})
(Media_Stream_Handler_Codec[])Playing
−
b
Sending
−
b
Event
−
y
Emitted when the connection manager wishes to place the stream on hold (so the streaming client should free hardware or software resources) or take the stream off hold (so the streaming client should reacquire the necessary resources).
When placing a channel's streams on hold, the connection manager SHOULD notify the remote contact that this will be done (if appropriate in the protocol) before it emits this signal.
It is assumed that relinquishing a resource will not fail. If it does, the call is probably doomed anyway.
When unholding a channel's streams, the connection manager SHOULD emit this signal and wait for success to be indicated via HoldState before it notifies the remote contact that the channel has been taken off hold.
This means that if a resource is unavailable, the remote contact will never even be told that we tried to acquire it.
Added in version 0.17.3.
Held
−
b
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Media_Stream_Error_Unknown = 0
Media_Stream_Error_EOS = 1
Media_Stream_Base_Proto_UDP = 0
Media_Stream_Base_Proto_TCP = 1
Media_Stream_Transport_Type_Local = 0
Media_Stream_Transport_Type_Derived = 1
Media_Stream_Transport_Type_Relay = 2
In bindings that need a separate name, arrays of Media_Stream_Handler_Candidate should be called Media_Stream_Handler_Candidate_List.
Name
−
s
Transports
−
a(usuussduss)
(Media_Stream_Handler_Transport[])In bindings that need a separate name, arrays of Media_Stream_Handler_Transport should be called Media_Stream_Handler_Transport_List.
Component_Number
−
u
IP_Address
−
s
Port
−
u
Protocol
−
u
(Media_Stream_Base_Proto)Subtype
−
s
Profile
−
s
Preference_Value
−
d
Transport_Type
−
u
(Media_Stream_Transport_Type)Username
−
s
Password
−
s
In bindings that need a separate name, arrays of Media_Stream_Handler_Codec should be called Media_Stream_Handler_Codec_List.
Codec_ID
−
u
Name
−
s
Media_Type
−
u
(Media_Stream_Type)Clock_Rate
−
u
Number_Of_Channels
−
u
Parameters
−
a{ss}
(String_String_Map)Interface for channels and other objects, to allow querying and setting properties. ListProperties returns which properties are valid for the given channel, including their type, and an integer handle used to refer to them in GetProperties, SetProperties, and the PropertiesChanged signal. The values are represented by D-Bus variant types, and are accompanied by flags indicating whether or not the property is readable or writable.
Each property also has a flags value to indicate what methods are available. This is a bitwise OR of PropertyFlags values.
Properties
−
au
(Property_ID[])Values
−
a(uv)
(Property_Value[])An array of structs containing:
org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.PermissionDenied
Available_Properties
−
a(ussu)
(Property_Spec[])Takes an array of (identifier, value) pairs containing desired values to set the given properties. In the case of any errors, no properties will be changed. When the changes have been acknowledged by the server, the PropertiesChanged signal will be emitted.
All properties given must have the PROPERTY_FLAG_WRITE flag, or PermissionDenied will be returned. If any variants are of the wrong type, NotAvailable will be returned. If any given property identifiers are invalid, InvalidArgument will be returned.
Properties
−
a(uv)
(Property_Value[])org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.NetworkError
Properties
−
a(uv)
(Property_Value[])An array of structs containing:
The array should contain only properties whose values have actually changed.
Properties
−
a(uu)
(Property_Flags_Change[])An array of structs containing:
The array should contain only properties whose flags have actually changed.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Property_Flag_Read = 1
Property_Flag_Write = 2
In bindings that need a separate name, arrays of Property_Spec should be called Property_Spec_List.
Property_ID
−
u
Name
−
s
Signature
−
s
(DBus_Signature)Flags
−
u
(Property_Flags)In bindings that need a separate name, arrays of Property_Flags_Change should be called Property_Flags_Change_List.
Property_ID
−
u
New_Flags
−
u
In bindings that need a separate name, arrays of Property_Value should be called Property_Value_List.
Identifier
−
u
(Property_ID)Value
−
v
The account manager is a central service used to store account details.
The current account manager is defined to be the process that owns the well-known bus name org.freedesktop.Telepathy.AccountManager on the session bus. This process must export an /org/freedesktop/Telepathy/AccountManager object with the AccountManager interface.
Until a mechanism exists for making a reasonable automatic choice of AccountManager implementation, implementations SHOULD NOT register as an activatable service for the AccountManager's well-known bus name. Instead, it is RECOMMENDED that some component of the user's session will select and activate a particular implementation, and that other Telepathy-enabled programs can detect whether Telepathy is in use by checking whether the AccountManager's well-known name is in use at runtime.
Added in version 0.17.2.
Connection_Manager
−
s
(Connection_Manager_Name)Protocol
−
s
(Protocol)Display_Name
−
s
Parameters
−
a{sv}
Account
−
o
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.InvalidArgument
Account
−
o
Account
−
o
Valid
−
b
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyValidAccounts
− ao
, read-onlyInvalidAccounts
− ao
, read-onlyAn Account object encapsulates the necessary details to make a Telepathy connection.
Accounts are uniquely identified by object path. The object path
of an Account MUST take the form
/org/freedesktop/Telepathy/Account/cm/proto/acct
, where:
This API avoids specifying the "profiles" used in Mission Control 4.x or the "presets" that have been proposed to replace them. An optional interface will be provided for AM implementations that want to provide presets.
There is deliberately no functionality here for opening channels; we intend to provide that in the channel dispatcher.
Other missing features which would be better in their own interfaces:
Added in version 0.17.2.
Changed in version 0.17.6: moved the Avatar property to a separate interface
org.freedesktop.Telepathy.Error.PermissionDenied
DBus_Property
, the change will be applied to the
corresponding D-Bus Property on the active
Connection if there is one; changes to
other parameters will not take effect until the next time the account
is disconnected and reconnected.
Changed in version 0.17.16: parameters which are also D-Bus properties can and should be updated on existing Connections
Set
−
a{sv}
Unset
−
as
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.InvalidArgument
Properties
−
a{sv}
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyDisplayName
− s
, read/writeIcon
− s
, read/writeValid
− b
, read-onlyEnabled
− b
, read/writeThis property gives the users the possibility to prevent an account from being used. This flag does not change the validity of the account.
A disabled account can never be put online.
Use cases:
The AccountManager SHOULD allow this property to be set on invalid accounts, but MUST NOT attempt to put invalid accounts online even if they become Enabled.
There doesn't seem to be any good reason not to allow this.
Nickname
− s
, read/writeParameters
− a{sv}
, read-onlyA map from connection manager parameter names (as in the ConnectionManager interface) to their values. This property includes only those parameters that are stored for this account, and SHOULD only include those parameters that the user has explicitly set.
This property cannot be altered using Set() - use UpdateParameters instead.
AutomaticPresence
− (uss)
(Simple_Presence), read/writeThe presence status that this account should have if it is brought online.
Setting this property MUST NOT actually change the account's status until the next time it is (re)connected for some reason.
The Connection_Presence_Type in the structure SHOULD NOT be Offline or Unset.
ConnectAutomatically
− b
, read/writeConnection
− o
, read-onlyEither the object path of the Connection to
this account, or the special value '/'
if there is no
connection.
If this object path is not '/', the Connection's well-known bus name can be derived from this object path by removing the first '/' and replacing subsequent '/' characters with '.'.
ConnectionStatus
− u
, read-onlyConnectionStatusReason
− u
, read-onlyCurrentPresence
− (uss)
(Simple_Presence), read-onlyRequestedPresence
− (uss)
(Simple_Presence), read/writeThe requested presence for this account. When this is changed, the account manager should attempt to manipulate the connection manager to make CurrentPresence match RequestedPresence as closely as possible. It should not be saved to any sort of persistent storage.
When the account manager automatically connects an account, it must signal this by setting the RequestedPresence to the same thing as the AutomaticPresence.
NormalizedName
− s
, read-onlyThe normalized user ID of the local user on this account (i.e. the string returned when the InspectHandles method is called on the result of GetSelfHandle for an active connection).
It is unspecified whether this user ID is globally unique.
As currently implemented, IRC user IDs are only unique within the same IRCnet. On some saner protocols, the user ID includes a DNS name which provides global uniqueness.
If this value is not known yet (which will always be the case for accounts that have never been online), it will be an empty string.
It is possible that this value will change if the connection manager's normalization algorithm changes, although this SHOULD be avoided.
It's not always completely clear what normalization algorithm should be used; for instance, in Gabble, we currently use JIDs, but it would also have been reasonable to use xmpp URIs.
Implementations of this interface must also implement:
This interface extends the core Account interface to provide a user-settable avatar image.
The avatar could have been a property on the core Account interface, but was moved to a separate interface because it is likely to be large. This means that clients can safely use GetAll to get properties on the core Account interface without flooding the session bus with large images.
Added in version 0.17.6.
Interface has no methods.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Avatar
− (ays)
(Avatar), read/writeA struct containing avatar data marked with its MIME type.
Arrays of Avatar don't generally make sense.
Avatar_Data
−
ay
MIME_Type
−
s
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
The channel dispatcher is responsible for responding to new channels and launching client processes to handle them. It also provides functionality for client processes to request that new channels are created.
If a channel dispatcher is running, it is responsible for dispatching new channels on all Connections created by the AccountManager. Connections not created by the AccountManager are outside the scope of the channel dispatcher.
Connections created by standalone Telepathy clients that do not intend to interact with the channel dispatcher should be ignored - otherwise, the channel dispatcher would try to launch handlers for channels that the standalone client was already handling internally.
The current channel dispatcher is defined to be the process that
owns the well-known bus name
org.freedesktop.Telepathy.ChannelDispatcher
on
the session bus. This process MUST export an object with this
interface at the object path
/org/freedesktop/Telepathy/ChannelDispatcher
.
Until a mechanism exists for making a reasonable automatic choice of ChannelDispatcher implementation, implementations SHOULD NOT register as an activatable service for the ChannelDispatcher's well-known bus name. Instead, it is RECOMMENDED that some component of the user's session will select and activate a particular implementation, and that other Telepathy-enabled programs can detect whether channel request/dispatch functionality is available by checking whether the ChannelDispatcher's well-known name is in use at runtime.
There are three categories of client process defined by this specification:
Observers monitor the creation of new channels. This functionality can be used for things like message logging. All observers are notified simultaneously.
Approvers notify the user that new channels have been created, and also select which channel handler will be used for the channel, either by asking the user or by choosing the most appropriate channel handler.
Each new channel or set of channels is passed to exactly one handler as its final destination. A typical channel handler is a user interface process handling channels of a particular type.
Start a request to create a channel. This initially just creates a ChannelRequest.DRAFT object, which can be used to continue the request and track its success or failure.
The request can take a long time - in the worst case, the channel dispatcher has to ask the account manager to put the account online, the account manager has to ask the operating system to obtain an Internet connection, and the operating system has to ask the user whether to activate an Internet connection using an on-demand mechanism like dialup.
This means that using a single D-Bus method call and response to represent the whole request will tend to lead to that call timing out, which is not the behaviour we want.
If this method is called for an Account that is disabled, invalid or otherwise unusable, no error is signalled until ChannelRequest.DRAFT.Proceed is called, at which point ChannelRequest.DRAFT.Failed is emitted with an appropriate error.
This means there's only one code path for errors, apart from InvalidArgument for "that request makes no sense".
It also means that the request will proceed if the account is enabled after calling CreateChannel, but before calling Proceed.
Account
−
o
Requested_Properties
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties. This has the same semantics as the corresponding parameter to Connection.Interface.Requests.CreateChannel.
Certain properties will not necessarily make sense in this dictionary: for instance, TargetHandle can only be given if the requester is able to interact with a Connection to the desired account.
User_Action_Time
−
x
(Unix_Timestamp64)The time at which user action occurred, or 0 if this channel
request is for some reason not involving user action.
The UserActionTime
property will be set to this value, and it will eventually be
passed as the User_Action_Time
parameter of HandleChannels.
Preferred_Handler
−
s
(DBus_Well_Known_Name)Either the well-known bus name (starting with
org.freedesktop.Telepathy.Client.
)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
acceptable. The channel dispatcher SHOULD dispatch as many as
possible of the resulting channels (ideally, all of them)
to that handler, and SHOULD remember the preferred handler
so it can try to dispatch subsequent channels in the same bundle
to the same handler.
This must be the well-known bus name, not the unique name, to ensure that all handlers do indeed have the Client API, and the Client object on the handler can be located easily.
This is partly so the channel dispatcher can call HandleChannels on it, and partly so the channel dispatcher can recover state if it crashes and is restarted.
If this is a well-known bus name, the channel dispatcher SHOULD call AddRequest on that Handler after this method has returned.
This ordering allows a Handler which calls CreateChannel with itself as the preferred handler to associate the call to AddRequest with that call.
Request
−
o
org.freedesktop.Telepathy.Error.InvalidArgument
Start a request to ensure that a channel exists, creating it if necessary. This initially just creates a ChannelRequest.DRAFT object, which can be used to continue the request and track its success or failure.
If this method is called for an Account that is disabled, invalid or otherwise unusable, no error is signalled until ChannelRequest.DRAFT.Proceed is called, at which point ChannelRequest.DRAFT.Failed is emitted with an appropriate error.
The rationale is as for CreateChannel.
Account
−
o
Requested_Properties
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties. This has the same semantics as the corresponding parameter to Connection.Interface.Requests.EnsureChannel.
Certain properties will not necessarily make sense in this dictionary: for instance, TargetHandle can only be given if the requester is able to interact with a Connection to the desired account.
User_Action_Time
−
x
(Unix_Timestamp64)The time at which user action occurred, or 0 if this channel
request is for some reason not involving user action.
The UserActionTime
property will be set to this value, and it will eventually be
passed as the User_Action_Time
parameter of HandleChannels.
Preferred_Handler
−
s
(DBus_Well_Known_Name)Either the well-known bus name (starting with
org.freedesktop.Telepathy.Client.
)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
acceptable.
This must be the well-known bus name, not the unique name, to ensure that all handlers do indeed have the Client API, and the Client object on the handler can be located easily.
This is partly so the channel dispatcher can call HandleChannels on it, and partly so the channel dispatcher can recover state if it crashes and is restarted.
If this is a well-known bus name, the channel dispatcher SHOULD call AddRequest on that Handler after this method has returned.
This ordering allows a Handler which calls EnsureChannel with itself as the preferred handler to associate the call to AddRequest with that call.
If any new channels are created in response to this
request, the channel dispatcher SHOULD dispatch as many as
possible of the resulting channels (ideally, all of them)
to that handler, and SHOULD remember the preferred handler
so it can try to dispatch subsequent channels in the same bundle
to the same handler. If the requested channel already exists (that
is, Connection.Interface.Requests.EnsureChannel
returns Yours=False
) then the channel dispatcher
SHOULD re-dispatch the channel to its existing handler, and MUST
NOT dispatch it to this client (unless it is the existing handler);
the request is still deemed to have succeeded in this case.
An address book application, for example, might call EnsureChannel
to ensure that a text channel with a particular contact is
displayed to the user; it does not care whether a new channel was
made. An IM client might call EnsureChannel
in response to the user double-clicking an entry in the contact
list, with itself as the Preferred_Handler
; if the
user already has a conversation with that contact in another
application, they would expect the existing window to be
presented, rather than their double-click leading to an error
message. So the request should succeed, even if its
Preferred_Handler
is not used.
Request
−
o
org.freedesktop.Telepathy.Error.InvalidArgument
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyThis interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
This interface allows users of the ChannelDispatcher to enumerate all the pending dispatch operations, with change notification.
The existence of the DispatchOperations property allows a newly started approver to pick up existing dispatch operations.
This is on a separate interface so clients that aren't interested in doing this aren't woken up by its signals.
Interface has no methods.
Emitted when a dispatch operation is added to DispatchOperations.
Dispatch_Operation
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Dispatch_Operation
−
o
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
DispatchOperations
− a(oa{sv})
(Dispatch_Operation_Details[]), read-onlyThe list of ChannelDispatchOperation objects currently being processed. Change notification is via the NewDispatchOperation and DispatchOperationFinished signals.
In bindings that need a separate name, arrays of Dispatch_Operation_Details should be called Dispatch_Operation_Details_List.
Channel_Dispatch_Operation
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Properties of the channel dispatch operation.
Connection managers MUST NOT include properties in this mapping if their values can change. Clients MUST ignore properties that appear in this mapping if their values can change.
The rationale is the same as for Channel_Details.
Each dictionary MUST contain at least the following keys:
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
A channel dispatch operation is an object in the ChannelDispatcher representing a bundle of unrequested channels being announced to client Approver.DRAFT processes.
These objects can result from new incoming channels or channels which are automatically created for some reason, but cannot result from outgoing requests for channels.
More specifically, whenever the Connection.Interface.Requests.NewChannels signal contains channels whose Requested property is false, or whenever the Connection.NewChannel signal contains a channel with suppress_handler false, one or more ChannelDispatchOperation objects are created for those channels.
(If some channels in a NewChannels signal are in different bundles, this is an error. The channel dispatcher SHOULD recover by treating the NewChannels signal as if it had been several NewChannels signals each containing one channel.)
First, the channel dispatcher SHOULD construct a list of all the Handler.DRAFTs that could handle all the channels (based on their HandlerChannelFilter property), ordered by priority in some implementation-dependent way. If there are handlers which could handle all the channels, one channel dispatch operation SHOULD be created for all the channels. If there are not, one channel dispatch operation SHOULD be created for each channel, each with a list of channel handlers that could handle that channel.
When listing channel handlers, priority SHOULD be given to channel handlers that are already handling channels from the same bundle.
If a handler with BypassApproval
= True
could handle the channels in the dispatch
operation, then the channel dispatcher SHOULD call HandleChannels
on that handler, and (assuming the call succeeds) emit
Finished and stop processing those
channels without involving any approvers.
Some channel types can be picked up "quietly" by an existing channel handler. If a Text channel is added to an existing bundle containing a StreamedMedia channel, there shouldn't be any approvers, flashing icons or notification bubbles, if the the UI for the StreamedMedia channel can just add a text box and display the message.
Otherwise, the channel dispatcher SHOULD send the channel dispatch operation to all relevant approvers (in parallel) and wait for an approver to claim the channels or request that they are handled. See AddDispatchOperation for more details on this.
Finally, if the approver requested it, the channel dispatcher SHOULD send the channels to a handler.
Called by an approver to accept a channel bundle and request that the given handler be used to handle it.
If successful, this method will cause the ChannelDispatchOperation object to disappear, emitting Finished.
However, this method may fail because the dispatch has already been completed and the object has already gone. If this occurs, it indicates that another approver has asked for the bundle to be handled by a particular handler. The approver MUST NOT attempt to interact with the channels further in this case, unless it is separately invoked as the handler.
Approvers which are also channel handlers SHOULD use Claim instead of HandleWith to request that they can handle a channel bundle themselves.
(FIXME: list some possible errors)
If the channel handler raises an error from HandleChannels, this method MAY respond by raising that same error, even if it is not specifically documented here.
Handler
−
s
(DBus_Bus_Name)The well-known bus name (starting with
org.freedesktop.Telepathy.Client.
) of the channel
handler that should handle the channel.
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Client.
".
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.NotYours
Called by an approver to claim channels for handling internally. If this method is called successfully, the process calling this method becomes the handler for the channel, but does not have the HandleChannels method called on it.
Clients that call Claim on channels but do not immediately close them SHOULD implement the Handler interface and its CurrentlyHandledChannels property.
Approvers wishing to reject channels MUST call this method to claim ownership of them, and MUST NOT call Close on the channels unless/until this method returns successfully.
The channel dispatcher can't know how best to close arbitrary channel types, so it leaves it up to the approver to do so. For instance, for Text channels it is necessary to acknowledge any messages that have already been displayed to the user first - ideally, the approver would display and then acknowledge the messages.
If successful, this method will cause the ChannelDispatchOperation object to disappear, emitting Finished, in the same way as for HandleWith.
This method may fail because the dispatch operation has already been completed. Again, see HandleWith for more details. The approver MUST NOT attempt to interact with the channels further in this case.
(FIXME: list some other possible errors)
org.freedesktop.Telepathy.Error.NotYours
Channel
−
o
Error
−
s
(DBus_Error_Name)The name of a D-Bus error indicating why the channel closed. If
no better reason can be found,
org.freedesktop.Telepathy.Errors.NotAvailable
MAY
be used as a fallback; this means that this error SHOULD NOT be
given any more specific meaning.
FIXME: or should we invent a new OtherError for that purpose?
FIXME: we need to specify errors for these situations:
Message
−
s
Emitted when this dispatch operation finishes. The dispatch operation is no longer present and further methods must not be called on it.
Its object path SHOULD NOT be reused for a subsequent dispatch operation; the ChannelDispatcher MUST choose object paths in a way that avoids immediate re-use.
Otherwise, clients might accidentally call HandleWith or Claim on a new dispatch operation instead of the one they intended to handle.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyConnection
− o
, read-onlyAccount
− o
, read-onlyChannels
− a(oa{sv})
(Channel_Details[]), read-onlyPossibleHandlers
− as
(DBus_Well_Known_Name[]), read-onlyThis interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
A channel request is an object in the ChannelDispatcher representing an ongoing request for some channels to be created or found. There can be any number of ChannelRequest objects at the same time.
Its well-known bus name is the same as that of the ChannelDispatcher, "org.freedesktop.Telepathy.ChannelDispatcher".
See ChannelDispatcher.DRAFT.CreateChannel for rationale for ChannelRequest being a separate object.
Proceed with the channel request.
The client that created this object calls this method when it has connected signal handlers for Succeeded and Failed.
Clients other than the client which created the ChannelRequest MUST NOT call this method.
This method SHOULD return immediately; on success, the request might still fail, but this will be indicated asynchronously by the Failed signal.
Proceed cannot fail, unless clients have got the life-cycle of a ChannelRequest seriously wrong (e.g. a client calls this method twice, or a client that did not create the ChannelRequest calls this method). If it fails, clients SHOULD assume that the whole ChannelRequest has become useless.
org.freedesktop.Telepathy.Errors.NotAvailable
Cancel the channel request. The precise effect depends on the current progress of the request.
If the connection manager has not already been asked to create a channel, then Failed is emitted immediately, and the channel request is removed.
If the connection manager has already been asked to create a channel but has not produced one yet (e.g. if Connection.Interface.Requests.CreateChannel has been called, but has not yet returned), then the ChannelDispatcher will remember that the request has been cancelled. When the channel appears, it will be closed (if it was newly created and can be closed), and will not be dispatched to a handler.
If the connection manager has already returned a channel, but the channel has not yet been dispatched to a handler then the channel dispatcher will not dispatch that channel to a handler. If the channel was newly created for this request, the channel dispatcher will close it with Close; otherwise, the channel dispatcher will ignore it. In either case, Failed will be emitted when processing has been completed.
If Failed is emitted in response to
this method, the error SHOULD be
org.freedesktop.Telepathy.Errors.Cancelled
.
If the channel has already been dispatched to a handler, then it's too late to call this method, and the channel request will no longer exist.
The channel request has failed. It is no longer present, and further methods must not be called on it.
Error
−
s
(DBus_Error_Name)The name of a D-Bus error. This can come from various sources, including the error raised by CreateChannel, or an error generated to represent failure to establish the Connection.
Message
−
s
The channel request has succeeded. It is no longer present, and further methods must not be called on it.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Account
− o
, read-onlyUserActionTime
− x
(Unix_Timestamp64), read-onlyThe time at which user action occurred, or 0 if this channel request is for some reason not involving user action.
This corresponds to the _NET_WM_USER_TIME property in EWMH.
This property is set when the channel request is created, and can never change.
Requests
− aa{sv}
(Qualified_Property_Value_Map[]), read-onlyAn array of dictionaries containing desirable properties for the channel or channels to be created.
This is an array so that we could add a CreateChannels method in future without redefining the API of ChannelRequest.
This property is set when the channel request is created, and can never change.
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Telepathy clients use connection managers, the channel dispatcher and optionally the account manager to provide useful functionality.
User interface processes are the obvious example of Telepathy clients, but they can provide other functionality, such as address-book synchronization.
Every running or activatable process with a well-known name of the form org.freedesktop.Telepathy.Client.clientname should be probed by the channel dispatcher to discover its capabilities. Each client is either an observer, an approver, a channel handler, or some combination of these.
Activatable services (those with a D-Bus .service
file) must be supported so that we can run clients
in response to channel creation.
Non-activatable services (those that do not register a D-Bus
.service
file for their well-known name, but do
request it at runtime) must be supported so that we can have
programs that process channels, but only if they are already
running - for instance, a full-screen media centre
application might do this.
The client name, clientname, MUST be a non-empty string of ASCII digits, letters, dots and/or underscores, starting with a letter, and without sets of two consecutive dots or a dot followed by a digit. For non-activatable services, it MAY contain a part that is generated per instance at runtime.
If each of a client Foo's instances should be able to manipulate
channels separately, the instance with unique name
:1.25
might request a well-known name like
org.freedesktop.Telepathy.Client.Foo._1._25
.
(Note that well-known bus-name components may not start with a digit, so o.f.T.Client.Foo.1.25 would not be acceptable.)
Each Client MUST export an object whose object path may be determined by replacing '.' with '/' in the well-known name and prepending '/'. This object represents its API as a Telepathy client; the channel dispatcher will call its methods and read its properties when appropriate.
As an optimization, activatable clients SHOULD install a file
$XDG_DATA_DIRS/telepathy/clients/clientname.client
containing a cached version of its immutable properties,
so that for most clients, the channel dispatcher can
just read a file to discover capabilities, instead of
having to service-activate the client immediately in order to fetch
its read-only properties. However, the D-Bus API is canonical, and
the channel dispatcher MUST support clients without such a file.
Non-activatable clients MAY install a .client
file,
but there's not much point in them doing so.
The .client files MUST contain UTF-8 text with the same syntax
as
Desktop
Entry files (although the allowed groups, keys and values differ).
Every .client
file MUST contain a group whose name is
the name of this interface.
The groups, keys and values in the .client
file are
defined by individual interfaces. Each interface that can usefully
cache information in the .client
file SHOULD correspond
to a group with the same name.
Added in version 0.17.12. (as a draft)
Interface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyA list of the extra interfaces provided by this client. This SHOULD include at least one of Client.Observer, Client.Approver or Client.Handler.
In the .client
file, this is represented by key
"Interfaces
" in the group named after this interface.
The value of the key is a list of interface names each followed by
a semicolon (so it always ends with a semicolon unless it is empty),
i.e. a key of type "strings" as described in the Desktop Entry
specification.
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Observers monitor the creation of new channels. This functionality can be used for things like message logging. All observers are notified simultaneously.
Observers SHOULD NOT modify the state of a channel except via user interaction.
We want Observer UIs for file transfer channels (a progress bar for the transfer) to be able to have a Cancel button.
Observers MUST NOT carry out actions that exactly one process must take responsibility for (e.g. acknowledging Text messages, or carrying out the actual transfer in a file transfer channel).
Since arbitrarily many observers can be activated for each channel, it would not make sense for observers to do things that can only be done by one process (acknowledging Text messages, carrying out streaming for StreamedMedia channels, doing the actual data transfer for file transfers, setting up the out-of-band connection for Tubes). The Handler is responsible for such tasks.
Handlers MAY, of course, delegate responsibility for these tasks to other processes (including those run as observers), but this MUST be done explicitly via a request from the Handler to the Observer.
Whenever new channels are signalled, the channel dispatcher will notify all running or activatable observers whose ObserverChannelFilter property (possibly as cached in the .client file) indicates that they are interested in the channel.
Observers are activated for all channels in which they have registered an interest - incoming, outgoing or automatically created - although of course the ObserverChannelFilter property can be set to filter on the Requested property.
Added in version 0.17.12. (as a draft)
Called by the channel dispatcher when channels in which the observer has registered an interest are created.
The observer MUST NOT return from this method call until it is ready for a handler for the channel to run (which may change the channel's state).
The channel dispatcher must wait for observers to start up, to avoid the following race: text channel logger (observer) gets ObserveChannel, text channel handler gets HandleChannels channel handler starts up faster and acknowledges messages, logger never sees those messages.
Account
−
o
Connection
−
o
Channels
−
a(oa{sv})
(Channel_Details[])DispatchOperation
−
o
Observer_Info
−
a{sv}
Additional information about these channels. No keys are currently defined.
If keys are defined for this dictionary, all will be optional; observers MAY safely ignore any entry in this dictionary.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ObserverChannelFilter
− aa{sv}
(Channel_Class[]), read-onlyA specification of the channels in which this observer is interested. The ObserveChannels method should be called by the channel dispatcher whenever any of the new channels in a NewChannels signal match this description.
(FIXME: open issue: do we want this, and the corresponding Approver and Handler properties, to be able to change at runtime?)
Only certain D-Bus types have useful semantics for matching like this, so only certain types are allowed:
This property never changes while the observer process is running. For activatable processes, the filter can change due to an upgrade - the channel dispatcher SHOULD observe changes to .client files using a mechanism like inotify.
For observers that have a .client file, the channel dispatcher
may discover this property from keys of the form
propertyname/type
,
in groups in the .client file whose name is the name of this
interface followed by .ObserverChannelFilter
,
a space and an ASCII decimal number starting from 0.
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).
For instance, a .client file for an observer that is only interested in Text channels, with CONTACT or ROOM handles, that were requested by a local client:
[org.freedesktop.Telepathy.Client.DRAFT] Interfaces=org.freedesktop.Telepathy.Client.Observer.DRAFT; [org.freedesktop.Telepathy.Client.Observer.DRAFT.ObserverChannelFilter 0] org.freedesktop.Telepathy.Channel.Type s=org.freedesktop.Telepathy.Channel.Type.Text org.freedesktop.Telepathy.Channel.TargetHandleType u=1 org.freedesktop.Telepathy.Channel.Requested b=true [org.freedesktop.Telepathy.Client.Observer.DRAFT.ObserverChannelFilter 1] org.freedesktop.Telepathy.Channel.Type s=org.freedesktop.Telepathy.Channel.Type.Text org.freedesktop.Telepathy.Channel.TargetHandleType u=2 org.freedesktop.Telepathy.Channel.Requested b=true
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Approvers notify the user that new channels have been created, and allow the user to accept or reject those channels.
They can also select which channel handler will be used for the channel, for instance by offering the user a list of possible handlers rather than just an accept/reject choice.
However, the Channel Dispatcher must be able to prioritize possible handlers on its own using some reasonable heuristic, probably based on user configuration.
It is possible (and useful) to have an approver and a channel handler in the same process; this is particularly useful if a channel handler wants to claim responsibility for particular channels itself.
All approvers are notified simultaneously. For instance, in a desktop system, there might be one approver that displays a notification-area icon, one that is part of a contact list window and highlights contacts there, and one that is part of a full-screen media player.
Any approver can approve the handling of a channel with a particular channel handler. Approvers can also request that the channel is rejected. The first approver to reply gets its decision acted on; any other approvers that reply at the same time will get a D-Bus error, indicating that the channel has already been dealt with.
Approvers should usually prompt the user and ask for confirmation, rather than dispatching the channel to a handler straight away.
Added in version 0.17.12. (as a draft)
Called by the channel dispatcher when a ChannelDispatchOperation in which the approver has registered an interest is created, or when the approver starts up while such channel dispatch operations already exist.
The channel dispatcher SHOULD call this method on all approvers at the same time. If no approvers return from this method successfully (including situations where there are no matching approvers at all), the channel dispatcher SHOULD consider this to be an error, and recover by dispatching the channel to the most preferred handler.
DispatchOperation
−
o
The ChannelDispatchOperation to be processed.
Properties
−
a{sv}
(Qualified_Property_Value_Map)Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ApproverChannelFilter
− aa{sv}
(Channel_Class[]), read-onlyA specification of the channels in which this approver is interested. The AddDispatchOperation method should be called by the channel dispatcher whenever the channels in a channel dispatch operation match this description.
(FIXME: what happens if some but not all of the channels match this?)
This property works in exactly the same way as the Client.Observer.DRAFT.ObserverChannelFilter property. In the .client file, it is represented in the same way as ObserverChannelFilter, but the group has the same name as this interface and the keys start with ApproverChannelFilter instead of ObserverChannelFilter.
This interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Channel handlers are the eventual handler for a channel or a channel bundle; a typical channel handler is a user interface process handling channels of a particular type.
When a new incoming channel (one with Requested = FALSE) is offered to Approvers by the channel dispatcher, it also offers the Approvers a list of all the running or activatable handlers whose HandlerChannelFilter property (possibly as cached in the .client file) indicates that they are able to handle the channel. The Approvers can choose one of those channel handlers to handle the channel.
When a new outgoing channel (one with Requested = TRUE) appears, the channel dispatcher passes it to an appropriate channel handler automatically.
Added in version 0.17.12. (as a draft)
Called by the channel dispatcher when this client should handle these channels, or when this client should present channels that it is already handling to the user (e.g. bring them into the foreground).
Clients are expected to know what channels they're already handling, and which channel object path corresponds to which window or tab. This can easily be done using a hash table keyed by channels' object paths.
This method can raise any D-Bus error. If it does, or if the handler loses its bus name before all the channels have closed, the handler is assumed to have failed or crashed, and the channel dispatcher MUST recover in an implementation-specific way.
It is RECOMMENDED that the channel dispatcher attempts to close the channels using Channel.Close, but resorts to calling Channel.Interface.Destroyable.Destroy (if available) or ignoring the channel (if not) if the same handler repeatedly fails to handle channels.
Account
−
o
Connection
−
o
Channels
−
a(oa{sv})
Requests_Satisfied
−
ao
User_Action_Time
−
t
Called by the ChannelDispatcher to indicate that channels have been requested, and that if the request is successful, they will be handled by this Handler.
This allows the UI to start preparing to handle the channels in advance (e.g. render a window with an "in progress" message), improving perceived responsiveness.
(FIXME: how do we know the returned channels will be handled by this handler? Do we just assume that they'll match the HandlerChannelFilter iff the request does?)
Request
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Called by the ChannelDispatcher to indicate that a request previously passed to AddRequest has failed and should be disregarded.
Request
−
o
Error
−
s
(DBus_Error_Name)The name of the D-Bus error with which the request failed.
If this is org.freedesktop.Telepathy.Errors.NotYours
,
this indicates that the request succeeded, but all the resulting
channels were given to some other handler.
Message
−
s
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
HandlerChannelFilter
− aa{sv}
(Channel_Class[]), read-onlyA specification of the channels that this channel handler can deal with. It will be offered to approvers as a potential channel handler for bundles that contain only suitable channels, or for suitable channels that must be handled separately.
This property works in exactly the same way as the Client.Observer.DRAFT.ObserverChannelFilter property. In the .client file, it is represented in the same way as ObserverChannelFilter, but the group has the same name as this interface and the keys start with HandlerChannelFilter instead of ObserverChannelFilter.
BypassApproval
− b
, read-onlyIf true, channels destined for this handler are automatically handled, without invoking approvers.
The intended usage is to allow a client handling one channel to
pick up closely related channels. Suppose a client capable of
handling both Text and StreamedMedia,
org.freedesktop.Telepathy.Client.Empathy
, is
handling a StreamedMedia channel. That client can take a second
well-known bus name, say
org.freedesktop.Telepathy.Client.Empathy._1._42.Bundle1
,
and configure an object at
/org/freedesktop/Telepathy/Client/Empathy/_1/_42/Bundle1
with BypassApproval = TRUE,
whose HandlerChannelFilter
matches closely related Text channels by their Bundle property.
(This is use-case dis5)
HandledChannels
− ao
, read-onlyA list of the channels that this Handler is currently handling.
There is no change notification.
This property exists for state recovery - it makes it possible for channel handling to survive a ChannelDispatcher crash.
If the channel dispatcher is automatically replaced, the replacement can discover all Handlers by looking for the Client well-known bus names, and discover which channels they are currently handling. Once this has been done, all unhandled channels can be re-dispatched, and the only issue visible to the user is that unhandled channels that they have already approved might be sent back to Approvers.
An interface exported by client applications which are able to handle incoming channels. This interface is intended to be deprecated in favour of Client.Handler.DRAFT when that interface comes out of DRAFT; client authors should consider implementing that interface instead.
Added in version 0.17.0.
Added in version 0.17.0.
Bus_Name
−
s
(DBus_Bus_Name)Connection
−
o
Channel_Type
−
s
(DBus_Interface)Channel
−
o
Handle_Type
−
u
(Handle_Type)Handle
−
u
(Handle)Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
In bindings that need a separate name, arrays of Qualified_Property_Value_Map should be called Qualified_Property_Value_Map_List.
Key
−
s
(DBus_Qualified_Member)Value
−
v
In bindings that need a separate name, arrays of String_Variant_Map should be called String_Variant_Map_List.
Key
−
s
Value
−
v
Key
−
s
Value
−
s
org.freedesktop.Telepathy.ConnectionManager
org.freedesktop.Telepathy.Connection
org.freedesktop.Telepathy.Connection.Interface.Aliasing
org.freedesktop.Telepathy.Connection.Interface.Avatars
org.freedesktop.Telepathy.Connection.Interface.Capabilities
org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT
org.freedesktop.Telepathy.Connection.Interface.ContactInfo.DRAFT
org.freedesktop.Telepathy.Connection.Interface.Contacts
org.freedesktop.Telepathy.Connection.Interface.Location.DRAFT
org.freedesktop.Telepathy.Connection.Interface.Presence
org.freedesktop.Telepathy.Connection.Interface.Renaming
org.freedesktop.Telepathy.Connection.Interface.Requests
org.freedesktop.Telepathy.Connection.Interface.SimplePresence
org.freedesktop.Telepathy.ChannelBundle.DRAFT
org.freedesktop.Telepathy.Channel
org.freedesktop.Telepathy.Channel.FUTURE
org.freedesktop.Telepathy.Channel.Type.ContactList
org.freedesktop.Telepathy.Channel.Type.StreamedMedia
org.freedesktop.Telepathy.Channel.Type.StreamedMedia.FUTURE
org.freedesktop.Telepathy.Channel.Type.RoomList
org.freedesktop.Telepathy.Channel.Type.Text
org.freedesktop.Telepathy.Channel.Type.Tubes
org.freedesktop.Telepathy.Channel.Type.StreamTube.DRAFT
org.freedesktop.Telepathy.Channel.Type.DBusTube.DRAFT
org.freedesktop.Telepathy.Channel.Type.FileTransfer
org.freedesktop.Telepathy.Channel.Interface.CallMerging
org.freedesktop.Telepathy.Channel.Interface.CallState
org.freedesktop.Telepathy.Channel.Interface.ChatState
org.freedesktop.Telepathy.Channel.Interface.Destroyable
org.freedesktop.Telepathy.Channel.Interface.DTMF
org.freedesktop.Telepathy.Channel.Interface.Group
org.freedesktop.Telepathy.Channel.Interface.Hold
org.freedesktop.Telepathy.Channel.Interface.HTML.DRAFT
org.freedesktop.Telepathy.Channel.Interface.Password
org.freedesktop.Telepathy.Channel.Interface.MediaSignalling
org.freedesktop.Telepathy.Channel.Interface.MediaSignalling.FUTURE
org.freedesktop.Telepathy.Channel.Interface.Messages
org.freedesktop.Telepathy.Channel.Interface.Tube.DRAFT
org.freedesktop.Telepathy.Media.SessionHandler
org.freedesktop.Telepathy.Media.StreamHandler
org.freedesktop.Telepathy.Properties
org.freedesktop.Telepathy.AccountManager
org.freedesktop.Telepathy.Account
org.freedesktop.Telepathy.Account.Interface.Avatar
org.freedesktop.Telepathy.ChannelDispatcher.DRAFT
org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList.DRAFT
org.freedesktop.Telepathy.ChannelDispatchOperation.DRAFT
org.freedesktop.Telepathy.ChannelRequest.DRAFT
org.freedesktop.Telepathy.Client.DRAFT
org.freedesktop.Telepathy.Client.Observer.DRAFT
org.freedesktop.Telepathy.Client.Approver.DRAFT
org.freedesktop.Telepathy.Client.Handler.DRAFT
org.freedesktop.Telepathy.ChannelHandler
Alias_Map
− a{ u → s }
Alias_Pair
− ( u, s )
Avatar
− ( ay, s )
Avatar_Token
− sAvatar_Token_Map
− a{ u → s }
Capability_Change
− ( u, s, u, u, u, u )
Capability_Pair
− ( s, u )
Channel_Call_State_Flags
− uChannel_Call_State_Map
− a{ u → u }
Channel_Chat_State
− uChannel_Class
− a{ s → v }
Channel_Details
− ( o, a{sv} )
Channel_Group_Change_Reason
− uChannel_Group_Flags
− uChannel_Info
− ( o, s, u, u )
Channel_Media_Capabilities
− uChannel_Password_Flags
− uChannel_Text_Message_Flags
− uChannel_Text_Message_Type
− uChannel_Text_Send_Error
− uConn_Mgr_Param_Flags
− uConnection_Alias_Flags
− uConnection_Capability_Flags
− uConnection_Manager_Name
− sConnection_Presence_Type
− uConnection_Status
− uConnection_Status_Reason
− uContact_Attribute
− sContact_Attributes_Map
− a{ u → a{sv} }
Contact_Capabilities_Map
− a{ u → a(a{sv}as) }
Contact_Capability
− ( u, s, u, u )
Contact_Handle
− uContact_Info_Field
− ( s, as, as )
Contact_Info_Field_Flags
− uContact_Info_Flag
− uContact_Info_Map
− a{ u → a(sasas) }
Contact_Locations
− a{ u → a{sv} }
Contact_Presences
− a{ u → (ua{sa{sv}}) }
DBus_Bus_Name
− sDBus_Error_Name
− sDBus_Interface
− sDBus_Member
− sDBus_Qualified_Member
− sDBus_Signature
− sDBus_Tube_Member
− ( u, s )
DBus_Tube_Participants
− a{ u → s }
DBus_Unique_Name
− sDBus_Well_Known_Name
− sDTMF_Event
− yDelivery_Reporting_Support_Flags
− uDelivery_Status
− uDispatch_Operation_Details
− ( o, a{sv} )
Field_Spec
− ( s, as, u, u )
File_Hash_Type
− uFile_Transfer_State
− uFile_Transfer_State_Change_Reason
− uGroup_Handle
− uHandle
− uHandle_Identifier_Map
− a{ u → s }
Handle_Owner_Map
− a{ u → u }
Handle_Type
− uLast_Activity_And_Statuses
− ( u, a{sa{sv}} )
List_Handle
− uLocal_Hold_State
− uLocal_Hold_State_Reason
− uLocal_Pending_Info
− ( u, u, u, s )
Location
− a{ s → v }
Location_Accuracy_Level
− iMedia_Session_Handler_Info
− ( o, s )
Media_Session_Type
− sMedia_Stream_Base_Proto
− uMedia_Stream_Direction
− uMedia_Stream_Error
− uMedia_Stream_Handler_Candidate
− ( s, a(usuussduss) )
Media_Stream_Handler_Codec
− ( u, s, u, u, u, a{ss} )
Media_Stream_Handler_Transport
− ( u, s, u, u, s, s, d, u, s, s )
Media_Stream_Info
− ( u, u, u, u, u, u )
Media_Stream_Pending_Send
− uMedia_Stream_State
− uMedia_Stream_Transport_Type
− uMedia_Stream_Type
− uMessage_ID
− uMessage_Part
− a{ s → v }
Message_Part_Content_Map
− a{ u → v }
Message_Part_Index
− uMessage_Part_Support_Flags
− uMessage_Sending_Flags
− uMultiple_Status_Map
− a{ s → a{sv} }
Param_Spec
− ( s, u, s, v )
Pending_Text_Message
− ( u, u, u, u, u, s )
Property_Flags
− uProperty_Flags_Change
− ( u, u )
Property_ID
− uProperty_Spec
− ( u, s, s, u )
Property_Value
− ( u, v )
Protocol
− sQualified_Property_Value_Map
− a{ s → v }
Requestable_Channel_Class
− ( a{sv}, as )
Rich_Presence_Access_Control
− ( u, v )
Rich_Presence_Access_Control_Type
− uRoom_Handle
− uRoom_Info
− ( u, s, a{sv} )
Sent_Message_Token
− sSimple_Contact_Presences
− a{ u → (uss) }
Simple_Presence
− ( u, s, s )
Simple_Status_Spec
− ( u, b, b )
Simple_Status_Spec_Map
− a{ s → (ubb) }
Single_Contact_Attributes_Map
− a{ s → v }
Socket_Access_Control
− uSocket_Address_IPv4
− ( s, q )
Socket_Address_IPv6
− ( s, q )
Socket_Address_Type
− uSocket_Netmask_IPv4
− ( s, y )
Socket_Netmask_IPv6
− ( s, y )
Status_Spec
− ( u, b, b, a{ss} )
Status_Spec_Map
− a{ s → (ubba{ss}) }
Stream_ID
− uString_String_Map
− a{ s → s }
String_Variant_Map
− a{ s → v }
Supported_Socket_Map
− a{ u → au }
Tube_Channel_State
− uTube_ID
− uTube_Info
− ( u, u, u, s, a{sv}, u )
Tube_State
− uTube_Type
− uUnix_Timestamp
− uUnix_Timestamp64
− x