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 Library 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.ContactInfoorg.freedesktop.Telepathy.Connection.Interface.Forwardingorg.freedesktop.Telepathy.Connection.Interface.Presenceorg.freedesktop.Telepathy.Connection.Interface.Privacyorg.freedesktop.Telepathy.Connection.Interface.Renamingorg.freedesktop.Telepathy.Channelorg.freedesktop.Telepathy.Channel.Type.ContactListorg.freedesktop.Telepathy.Channel.Type.ContactSearchorg.freedesktop.Telepathy.Channel.Type.StreamedMediaorg.freedesktop.Telepathy.Channel.Type.RoomListorg.freedesktop.Telepathy.Channel.Type.Textorg.freedesktop.Telepathy.Channel.Type.Tubesorg.freedesktop.Telepathy.Channel.Interface.ChatStateorg.freedesktop.Telepathy.Channel.Interface.DTMForg.freedesktop.Telepathy.Channel.Interface.Grouporg.freedesktop.Telepathy.Channel.Interface.Holdorg.freedesktop.Telepathy.Channel.Interface.Passwordorg.freedesktop.Telepathy.Channel.Interface.Transferorg.freedesktop.Telepathy.Channel.Interface.MediaSignallingorg.freedesktop.Telepathy.Media.SessionHandlerorg.freedesktop.Telepathy.Media.StreamHandlerorg.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. The names of these services, the protocols they support, and the parameters understood by that protocol are intended to be discovered by reading files on disk which are provided along with the connection manager. These are documented elsewhere.
Once a connection manager service has been activated, the object path of the manager object implementing this interface is always /org/freedesktop/Telepathy/ConnectionManager/name Where name is the identifier for the connection manager.
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.
proto -
sa(susv)org.freedesktop.Telepathy.Error.NotImplementedasRequest 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.
In order to allow Connection objects to be discovered by new clients, the object path and bus name must be of the form:
/org/freedesktop/Telepathy/Connection/manager/proto/account
And:
org.freedesktop.Telepathy.Connection.manager.proto.account
Where manager and proto are the identifiers for this manager and this protocol, and account is a series of elements 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, or on protocols where connecting multiple times is permissable, a per-connection identifier is also necessary to ensure uniqueness.
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.
proto -
sparameters -
a{sv}soorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentbus_name -
sobject_path -
oproto -
sInterface has no properties.
Conn_Mgr_Param_Flag_Required = 1Conn_Mgr_Param_Flag_Register = 2Conn_Mgr_Param_Flag_Has_Default = 4This 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.
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 GetInterfaces after the connection, has been established and must not change subsequently at runtime.
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.
org.freedesktop.Telepathy.Error.NotAvailableasorg.freedesktop.Telepathy.Error.Disconnectedsuorg.freedesktop.Telepathy.Error.DisconnecteduNotify 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 ReleaseHandle 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 -
uhandles -
auorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandlehandle_type -
uhandles -
auasorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandlea(osuu)An array of structs containing:
org.freedesktop.Telepathy.Error.Disconnectedhandle_type -
uhandles -
auorg.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 GetHandle() returns 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 -
shandle_type -
uhandle -
usuppress_handler -
boorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.Channel.Bannedorg.freedesktop.Telepathy.Error.Channel.Fullorg.freedesktop.Telepathy.Error.Channel.InviteOnlyhandle_type -
unames -
asauorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableobject_path -
ochannel_type -
shandle_type -
uhandle -
usuppress_handler -
bstatus -
ureason -
uInterface has no properties.
Handle_Type_None = 0Handle_Type_Contact = 1Handle_Type_Room = 2Handle_Type_List = 3Handle_Type_Group = 4Connection_Status_Connected = 0Connection_Status_Connecting = 1Connection_Status_Disconnected = 2Connection_Status_Reason_None_Specified = 0Connection_Status_Reason_Requested = 1Connection_Status_Reason_Network_Error = 2Connection_Status_Reason_Authentication_Failed = 3Connection_Status_Reason_Encryption_Error = 4Connection_Status_Reason_Name_In_Use = 5Connection_Status_Reason_Cert_Not_Provided = 6Connection_Status_Reason_Cert_Untrusted = 7Connection_Status_Reason_Cert_Expired = 8Connection_Status_Reason_Cert_Not_Activated = 9Connection_Status_Reason_Cert_Hostname_Mismatch = 10Connection_Status_Reason_Cert_Fingerprint_Mismatch = 11Connection_Status_Reason_Cert_Self_Signed = 12Connection_Status_Reason_Cert_Other_Error = 13Implementations 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.
uorg.freedesktop.Telepathy.Error.Disconnectedcontacts -
auasorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidHandlealiases -
a{us}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedaliases -
a(us)Interface has no 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.
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 unique (per contact) token which represents a hash or timestamp (depending on the protocol) of the contacts' avatar data. 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 GetAvatarTokens to request the tokens for the avatars of all the contacts it is interested in when it connects. The avatars can then be retreived using RequestAvatar for the corresponding contact. Clients should bind to the AvatarChanged 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, and set the avatar if it is an empty string (and may optionally replace it if the token corresponds to a different 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.
asqqqquorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontacts -
auasorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontacts -
aua{us}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontact -
uaysorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontacts -
auorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleavatar -
aymime_type -
ssorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorcontact -
unew_avatar_token -
scontact -
utoken -
savatar -
aytype -
sInterface has no properties.
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 can pertain to a certain contact handle, representing activities such as having a text chat or a voice call with the user, or can be on the connection itself (where the handle will be zero), where they represent the ability to create channels for chat rooms or activities such as searching and room listing. The activities are represented by the D-Bus interface name of the channel type for that activity.
The generic capability flags are defined by ConnectionCapabilityFlag.
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.
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 (as returned by GetSelfHandle) the 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)remove -
asa(su)org.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.Disconnectedhandles -
aua(usuu)org.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedcaps -
a(usuuuu)Interface has no properties.
Connection_Capability_Flag_Create = 1Connection_Capability_Flag_Invite = 2Implementations of this interface must also implement:
THIS INTERFACE IS DEPRECATED AND SHOULD NOT BE USED. A new version will be proposed in the 0.13 specification branch.
An interface for requesting information about a contact on a given connection. Information is returned as a vCard represented as an XML string, in the format defined by JEP-0054: vcard-temp specifiation from the Jabber Software Foundation (this is derived from the aborted IETF draft draft-dawson-vcard-xml-dtd-01).
Implementations using PHOTO or SOUND elements should use the URI encoding where possible, and not provide base64 encoded data to avoid unnecessary bus traffic. Clients should not implement support for these encoded forms. A separate interface will be provided for transferring user avatars.
The following extended element names are also added to represent information from other systems which are not based around vCards:
contact -
uorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontact -
uvcard -
sInterface has no properties.
Implementations of this interface must also implement:
A connection interface for services which can signal to contacts that they should instead contact a different user ID, effectively forwarding all incoming communication channels to another contact on the service.uorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableforward_to -
uorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidHandleforward_to -
uInterface has no properties.
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. Telepathy's definition of presence is based on that used by the Galago project (see http://www.galago-project.org/).
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 ConnectionPresenceType 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 -
sparms -
a{sv}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedcontacts -
aupresence -
a{u(ua{sa{sv}})}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailablea{s(ubba{ss})}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorstatus -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidArgumentcontacts -
auorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailabletime -
uorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedstatuses -
a{sa{sv}}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedpresence -
a{u(ua{sa{sv}})}Interface has no properties.
Connection_Presence_Type_Unset = 0Connection_Presence_Type_Offline = 1Connection_Presence_Type_Available = 2Connection_Presence_Type_Away = 3Connection_Presence_Type_Extended_Away = 4Connection_Presence_Type_Hidden = 5Implementations of this interface must also implement:
An interface to support getting and setting privacy modes to configure situations such as not being contactable by people who are not on your subscribe list. If this interface is not implemented, the default can be presumed to be allow-all (as defined in GetPrivacyModes).sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorasmode -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidArgumentmode -
sInterface has no properties.
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 -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedEmitted 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 -
unew -
uInterface has no properties.
All 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 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. There can be at most one channel for each combination of (channel type, handle type, handle) with nonzero handle type.
If a channel does not have a handle (an "anonymous channel"), 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. There can be any number of anonymous channels of the same channel type.
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.
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.NotAvailablesuuasInterface has no properties.
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 RequestHandle with a handle type of HANDLE_TYPE_LIST and one of the following identifiers:
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 RequestHandle 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 closing 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 properties.
Implementations of this interface must also implement:
A channel type for searching server-stored user directories. A new channel should be requested by a client for each search attempt, and it should be closed when the search is completed or the required result has been found in order to free unused handles. The search can be cancelled at any time by calling the channel Close method, although depending upon the protocol the connection manager may not be able to prevent the server from sending further results.
Before searching, the GetSearchKeys method should be used to discover any instructions sent by the server, and the valid search keys which can be provided to the Search method. A search request is then started by providing some of these terms to the Search method, and the search status will be set to CHANNEL_CONTACT_SEARCH_STATE_DURING. When results are returned by the server, the SearchResultReceived signal is emitted for each contact found, and when the search is complete, the search status will be set to CHANNEL_SEARCH_STATE_AFTER.
Returns any instructions from the server along with a dictionary of search key names to their types, and a boolean indicating if the key is mandatory. The following well-known search key names should be used where appropriate:
sa{s(bg)}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableuterms -
a{sv}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentcontact -
uvalues -
a{sv}state -
uInterface has no properties.
Channel_Contact_Search_State_Before = 0Channel_Contact_Search_State_During = 1Channel_Contact_Search_State_After = 2Implementations 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.
Channels of this type are expected to provide the Group interface and be "anonymous" (have no associated handle). To make a media call to a contact, clients should request a new, empty streamed media channel, then call AddMembers to add the contact to the channel. The local user should be in the group's members, while the contact should be in "remote pending" until the call is accepted, then move to the group's members.
Similarly, incoming calls should be signalled as having handle type 0 and handle 0. The remote contact should be in the group's members, with the local user in the "local pending" members; to accept the call, AddMembers can be used to move the local user to the group's members.
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.
a(uuuuuu)streams -
auorg.freedesktop.Telepathy.Error.InvalidArgumentRequest 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 -
ustream_direction -
uorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableRequest 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.
contact_handle -
utypes -
aua(uuuuuu)