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.ConnectionManagerorg.freedesktop.Telepathy.Connectionorg.freedesktop.Telepathy.Connection.Interface.Aliasingorg.freedesktop.Telepathy.Connection.Interface.Avatarsorg.freedesktop.Telepathy.Connection.Interface.Capabilitiesorg.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFTorg.freedesktop.Telepathy.Connection.Interface.ContactInfo.DRAFTorg.freedesktop.Telepathy.Connection.Interface.Contactsorg.freedesktop.Telepathy.Connection.Interface.Location.DRAFTorg.freedesktop.Telepathy.Connection.Interface.Presenceorg.freedesktop.Telepathy.Connection.Interface.Renamingorg.freedesktop.Telepathy.Connection.Interface.Requestsorg.freedesktop.Telepathy.Connection.Interface.SimplePresenceorg.freedesktop.Telepathy.ChannelBundle.DRAFTorg.freedesktop.Telepathy.Channelorg.freedesktop.Telepathy.Channel.FUTUREorg.freedesktop.Telepathy.Channel.Type.ContactListorg.freedesktop.Telepathy.Channel.Type.StreamedMediaorg.freedesktop.Telepathy.Channel.Type.StreamedMedia.FUTUREorg.freedesktop.Telepathy.Channel.Type.RoomListorg.freedesktop.Telepathy.Channel.Type.Textorg.freedesktop.Telepathy.Channel.Type.Tubesorg.freedesktop.Telepathy.Channel.Type.StreamTubeorg.freedesktop.Telepathy.Channel.Type.DBusTubeorg.freedesktop.Telepathy.Channel.Type.FileTransferorg.freedesktop.Telepathy.Channel.Type.ContactSearch.DRAFTorg.freedesktop.Telepathy.Channel.Interface.CallMergingorg.freedesktop.Telepathy.Channel.Interface.CallStateorg.freedesktop.Telepathy.Channel.Interface.ChatStateorg.freedesktop.Telepathy.Channel.Interface.Destroyableorg.freedesktop.Telepathy.Channel.Interface.DTMForg.freedesktop.Telepathy.Channel.Interface.Grouporg.freedesktop.Telepathy.Channel.Interface.Holdorg.freedesktop.Telepathy.Channel.Interface.HTML.DRAFTorg.freedesktop.Telepathy.Channel.Interface.Passwordorg.freedesktop.Telepathy.Channel.Interface.MediaSignallingorg.freedesktop.Telepathy.Channel.Interface.MediaSignalling.FUTUREorg.freedesktop.Telepathy.Channel.Interface.Messagesorg.freedesktop.Telepathy.Channel.Interface.Tubeorg.freedesktop.Telepathy.Media.SessionHandlerorg.freedesktop.Telepathy.Media.StreamHandlerorg.freedesktop.Telepathy.Debug.DRAFTorg.freedesktop.Telepathy.AccountManagerorg.freedesktop.Telepathy.Accountorg.freedesktop.Telepathy.Account.Interface.Avatarorg.freedesktop.Telepathy.ChannelDispatcherorg.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationListorg.freedesktop.Telepathy.ChannelDispatchOperationorg.freedesktop.Telepathy.ChannelRequestorg.freedesktop.Telepathy.Clientorg.freedesktop.Telepathy.Client.Observerorg.freedesktop.Telepathy.Client.Approverorg.freedesktop.Telepathy.Client.Handlerorg.freedesktop.Telepathy.Client.Interface.Requestsorg.freedesktop.Telepathy.ChannelHandlerorg.freedesktop.Telepathy.PropertiesA 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.NotImplementedProtocols −
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 −
oorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentBus_Name −
s (DBus_Bus_Name)Object_Path −
oProtocol −
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 = 1Conn_Mgr_Param_Flag_Register = 2Conn_Mgr_Param_Flag_Has_Default = 4Conn_Mgr_Param_Flag_Secret = 8This 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 = 16com.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 −
sFlags −
u (Conn_Mgr_Param_Flags)Signature −
s (DBus_Signature)Default_Value −
vImplementations of this interface must also implement:
org.freedesktop.Telepathy.Connection.Interface.Requestsorg.freedesktop.Telepathy.Connection.Interface.ContactsThis 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.SimplePresence 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.
Changed in version 0.17.23: The Requests and Contacts interfaces are now mandatory. Their functionality will be merged into the main Connection interface at some point in future.
Request that the connection be established. This will be done asynchronously and errors will be returned by emitting StatusChanged signals.
Calling this method on a Connection that is already connecting or connected is allowed, and has no effect.
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.DisconnectedProtocol −
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.DisconnectedStatus −
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.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandleHandle_Type −
u (Handle_Type)Handles −
au (Handle[])Identifiers −
asorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandleDeprecated since version 0.17.23. Use the Requests.Channels property instead.
Channel_Info −
a(osuu) (Channel_Info[])org.freedesktop.Telepathy.Error.DisconnectedHandle_Type −
u (Handle_Type)Handles −
au (Handle[])org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableRequest 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.
Deprecated since version 0.17.23. Use Requests.CreateChannel or Requests.EnsureChannel instead. Connection managers MAY implement RequestChannel by raising NotImplemented, or implement fewer types of channel via this API.
Type −
s (DBus_Interface)Handle_Type −
u (Handle_Type)Handle −
u (Handle)Suppress_Handler −
bObject_Path −
oorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.NotCapableorg.freedesktop.Telepathy.Error.Channel.Bannedorg.freedesktop.Telepathy.Error.Channel.Fullorg.freedesktop.Telepathy.Error.Channel.InviteOnlyHandle_Type −
u (Handle_Type)Names −
asHandles −
au (Handle[])org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotImplementedAdded 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)Deprecated since version 0.17.23. Connection managers MUST still emit this signal, but clients SHOULD listen for the Requests.NewChannels signal instead.
Object_Path −
oChannel_Type −
s (DBus_Interface)Handle_Type −
u (Handle_Type)Handle −
u (Handle)Suppress_Handler −
bIf 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 = 0Handle_Type_Contact = 1Handle_Type_Room = 2Handle_Type_List = 3Handle_Type_Group = 4Connection_Status_Connected = 0Connection_Status_Connecting = 1Connection_Status_Disconnected = 2A 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 = 0There 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 = 1The 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 = 2There 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 = 3The 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 = 4There 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 = 5In 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 = 6The 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 = 7The 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 = 8The 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 = 9The 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 = 10The 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 = 11The 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 = 12The 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 = 13There 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.
Deprecated since version 0.17.23.
In bindings that need a separate name, arrays of Channel_Info should be called Channel_Info_List.
Channel −
oChannel_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.DisconnectedContacts −
au (Contact_Handle[])Aliases −
asorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidHandleContacts −
au (Contact_Handle[])Aliases −
a{us} (Alias_Map)org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleAliases −
a{us} (Alias_Map)org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedAliases −
a(us) (Alias_Pair[])Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Connection_Alias_Flag_User_Set = 1The 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 −
sHandle −
u (Contact_Handle)Alias −
sImplementations 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.
Deprecated since version 0.17.22. Use GetAll to retrieve the D-Bus properties on this interface, falling back to this method on failure.
MIME_Types −
asMin_Width −
qMin_Height −
qMax_Width −
qMax_Height −
qMax_Bytes −
uorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableDeprecated since version 0.15.5. Use GetKnownAvatarTokens instead.
Contacts −
au (Contact_Handle[])Tokens −
as (Avatar_Token[])org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableContacts −
au (Contact_Handle[])Tokens −
a{us} (Avatar_Token_Map)org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableDeprecated since version 0.15.5. Use RequestAvatars instead.
Contact −
u (Contact_Handle)Data −
ayMIME_Type −
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableContacts −
au (Contact_Handle[])org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleAvatar −
ayMIME_Type −
sToken −
s (Avatar_Token)org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableAdded in version 0.15.0.
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorContact −
u (Contact_Handle)New_Avatar_Token −
s (Avatar_Token)Contact −
u (Contact_Handle)Token −
s (Avatar_Token)Avatar −
ayType −
sInterface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
SupportedAvatarMIMETypes − as, read-onlyAdded in version 0.17.22. Fall back to calling GetAvatarRequirements if getting this property fails.
MinimumAvatarHeight − u, read-onlyAdded in version 0.17.22. Fall back to calling GetAvatarRequirements if getting this property fails.
MinimumAvatarWidth − u, read-onlyAdded in version 0.17.22. Fall back to calling GetAvatarRequirements if getting this property fails.
RecommendedAvatarHeight − u, read-onlyAdded in version 0.17.22.
RecommendedAvatarWidth − u, read-onlyAdded in version 0.17.22.
MaximumAvatarHeight − u, read-onlyAdded in version 0.17.22. Fall back to calling GetAvatarRequirements if getting this property fails.
MaximumAvatarWidth − u, read-onlyAdded in version 0.17.22. Fall back to calling GetAvatarRequirements if getting this property fails.
MaximumAvatarBytes − u, read-onlyAdded in version 0.17.22. Fall back to calling GetAvatarRequirements if getting this property fails.
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 exp