Copyright (C) 2008 Nokia Corporation

Interfaces

org.freedesktop.Telepathy.Account

An 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

Methods:

Remove ( ) → nothing

Delete the account.

Possible errors

org.freedesktop.Telepathy.Error.PermissionDenied
(Undocumented.)

UpdateParameters ( a{sv}: Set, as: Unset ) → as

Change the value of the Parameters property.

If any of the changed parameters' Conn_Mgr_Param_Flags include 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.

In general, reconnecting is a destructive operation that shouldn't happen as a side-effect. In particular, migration tools that twiddle the settings of all accounts shouldn't cause an automatic disconnect and reconnect.

Changed in version 0.17.16: parameters which are also D-Bus properties can and should be updated on existing Connections

Changed in version 0.17.UNRELEASED: return an array of the parameters that won't change until the account is reconnected

Parameters

Seta{sv}
A mapping from parameter names to their values. These parameters should be stored for future use.
Unsetas
A list of the names of parameters to be removed from the set of stored values, allowing the default values to be used. If the given parameters were not, in fact, stored, or even if they do not exist at all, the account manager MUST accept this without error.

Returns

Reconnect_Requiredas
A list of the names of parameters with changes that will not take effect until the account is reconnected (this may be empty, e.g. if all the parameters are D-Bus properties or parameters for which the account manager has specific support). User interfaces that require "instant apply" semantics MAY call Reconnect in response to receiving a non-empty list.

Possible errors

org.freedesktop.Telepathy.Error.PermissionDenied
(Undocumented.)
org.freedesktop.Telepathy.Error.InvalidArgument
(Undocumented.)

Reconnect ( ) → nothing

Re-connect this account. If the account is currently disconnected and the requested presence is offline, or if the account is not Enabled or not Valid, this does nothing.

If the account is disconnected and the requested presence is not offline, this forces an attempt to connect with the requested presence immediately.

If the account is connecting or connected, this is equivalent to remembering the current value of RequestedPresence, setting its value to (OFFLINE, "offline", ""), waiting for the change to take effect, then setting its value to the value that was previously remembered.

Clients desiring "instant apply" semantics for CM parameters MAY call this method to achieve that.

In particular, if the account's Connection is in the Connecting state, calling this method causes the attempt to connect to be aborted and re-tried.

This is necessary to ensure that the new parameters are picked up.

Signals:

Removed ( )

This account has been removed.
This is redundant with AccountRemoved, but it's still worth having, to avoid having to bind to AccountManager.AccountRemoved to tell you whether your Account is valid — ideally, an account-editing UI should only care about a single Account.

AccountPropertyChanged ( a{sv}: Properties )

The values of one or more properties on this interface (that do not specify that this signal does not apply to them) may have changed. This does not cover properties of other interfaces, which must provide their own change notification if appropriate.

Parameters

Propertiesa{sv}
A map from property names in this namespace (e.g. Nickname) to values. Properties whose values have not changed SHOULD be omitted, but this need not be done.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Interfacesas (DBus_Interface[]), read-only
A list of the extra interfaces provided by this account.
DisplayNames, read/write
The user-visible name of this account. This SHOULD be chosen by the user at account creation time. The account creation user interface is responsible for setting a reasonable default value in the user's locale; something like "Jabber (bob@example.com)" would be sensible.
This approximately corresponds to "display name" in NMC 4.x and Decibel.
Icons, read/write
The name of an icon in the system's icon theme, such as "im-msn", or the empty string to not specify an icon. If the icon is set to an empty string, the account manager or any client MAY derive a default icon, for instance from the protocol.
This approximately corresponds to mc_profile_get_icon_name (or possibly mc_profile_get_branding_icon_name) in NMC 4.x. It's accessed via the account rather than the profile because we no longer have profiles as a core concept.
Validb, read-only
If true, this account is considered by the account manager to be complete and usable. If false, user action is required to make it usable, and it will never attempt to connect (for instance, this might be caused by the absence of a required parameter).
For connection managers with a plugin architecture, like telepathy-haze, we have little or no control over the parameters offered; for platforms with package management, we have little or no control over the CMs offered. NMC 4.x would just pretend the account didn't exist in these circumstances, but silent data loss is bad, and UIs with CM-specific knowledge (or a user filling in newly-required parameters) might be able to rescue a broken account.
Enabledb, read/write

This 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:

  • user has two or more accounts capable of calling contact X, but he doesn't want the UI to prompt him everytime about which one he wants to use for the call. He can then disable all the equivalent accounts but one.
  • There is some temporary server error and the user doesn't want to be be bother by error messages, or change the account configuration: temporarily disabling the account is quicker.

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.

Nicknames, read/write
The nickname to set on this account for display to other contacts, as set by the user. When the account becomes connected, the account manager SHOULD set this as the user's alias using SetAliases if appropriate.
In a later specification revision, we plan to separate the concepts of a contact's nickname as set by themselves, and the local name for them in our contact list (a "handle" or "pet name" as described in XEP-0165 and its references). The terminology change from alias to nickname here is a step in that direction. This corresponds to NMC 4.x mc_account_get_alias.
Parametersa{sv}, read-only

A 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.

This avoids NMC being tied to gconf as a matter of API.
AutomaticPresence(uss) (Simple_Presence), read/write

The 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.

In ITOS2007 and ITOS2008 this is a global preference, not visible on D-Bus (the "default presence"). "Automatic presence" better describes when it is used.
ConnectAutomaticallyb, read/write
If true, the account manager SHOULD attempt to put this account online with the AutomaticPresence whenever possible (in the base Account interface this is deliberately left vague). If false, it MUST NOT put the account online automatically in response to, for instance, connectivity changes, but SHOULD still put the account online with the AutomaticPresence if requested by the user (for instance, if the user tries to start a conversation using this account).
This approximately corresponds to NMC 4.x "enabled" and Decibel "autoreconnect".
Connectiono, read-only

Either 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 '.'.

Object paths aren't nullable, so we can't use an empty string.
ConnectionStatusu, read-only
If the Connection property is non-empty, the status of that connection. If the Connection property is the empty string, this property may either be Disconnected (indicating that the account manager is not attempting to bring it online), or Connecting (indicating that the account manager is attempting to connect). The account manager is expected to set this by observing signals from the Connection.
If the AM is doing some sort of backoff/delay on reconnection attempts, the account's status is conceptually "Connecting" even though there is no Connection. This vaguely corresponds to GetCurrentStatus in NMC 4.x.
ConnectionStatusReasonu, read-only
The reason for the last change to ConnectionStatus. The account manager is expected to set this by observing signals from the Connection.
If you weren't watching the Connection at the time it failed, you can't tell why - unless the AM can tell you. This is part of GetCurrentStatus in NMC 4.x.
CurrentPresence(uss) (Simple_Presence), read-only
The actual presence. If the connection is not online, this should be (Connection_Presence_Type_Offline, "", ""). If the connection is online but does not support the SimplePresence interface, this should be (Connection_Presence_Type_Unset, "", ""). The account manager is expected to set this by observing signals from the Connection.
This corresponds to GetPresenceActual in NMC 4.x.
RequestedPresence(uss) (Simple_Presence), read/write

The 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.

This corresponds to e.g. GetPresence and GetPresenceMessage in NMC 4.x.
NormalizedNames, read-only

The 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.

HasBeenOnlineb, read-only
If true, this account has successfully been put online at some point in the past.
UIs could apply a policy that the 'account' parameter can only be edited in accounts that have never been online, or that ConnectAutomatically cannot be set on such accounts. The account manager should not enforce such policies, but it can expose enough information to UIs that the UI can decide what to do.

org.freedesktop.Telepathy.Account.Interface.Avatar

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.

Signals:

AvatarChanged ( )

Emitted when the Avatar property changes.
The avatar itself is deliberately not included in this signal, to reduce bus traffic in the (likely common) case where no running application cares about the user's own avatar.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Avatar(ays) (Avatar), read/write
The avatar to set on this account for display to other contacts, represented as a structure containing the bytes of the avatar, and the MIME type as a string; may be set to an empty byte-array and an empty string to indicate no avatar. When the account becomes connected, the account manager SHOULD set this avatar using SetAvatar if appropriate.
This corresponds to NMC 4.x mc_account_get_avatar.

Structure types

Avatar − ( ay: Avatar_Data, s: MIME_Type )

A struct containing avatar data marked with its MIME type.

Arrays of Avatar don't generally make sense.

Members

Avatar_Dataay
(undocumented)
MIME_Types
(undocumented)

com.nokia.Account.Interface.ChannelRequests

Implementations of this interface must also implement:

The ChannelRequests interface provides methods to create and cancel channel requests, and signals to monitor them.

Methods:

Create ( a{sv}: Requested_Properties, t: User_Action_Time, s: Preferred_Handler ) → o

Create a channel request.

Parameters

Requested_Propertiesa{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_Timet

The time at which user action occurred, or 0 if this channel request is for some reason not involving user action. This value will eventually be passed as the User_Action_Time parameter of HandleChannels.

Preferred_Handlers (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.

Returns

Requesto
A ChannelRequest.DRAFT object. Currently the object itself is not implemented and this object path should be used only like a unique indentifier for the channel request.

Possible errors

org.freedesktop.Telepathy.Error.InvalidArgument
The Preferred_Handler is syntactically invalid or does not start with org.freedesktop.Telepathy.Client., the Account does not exist, or one of the Requested_Properties is invalid

EnsureChannel ( a{sv}: Requested_Properties, t: User_Action_Time, s: Preferred_Handler ) → o

Start a request to ensure that a channel exists, creating it if necessary.

Parameters

Requested_Propertiesa{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_Timet

The time at which user action occurred, or 0 if this channel request is for some reason not involving user action. This value will eventually be passed as the User_Action_Time parameter of HandleChannels.

Preferred_Handlers (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 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.

Returns

Requesto
A ChannelRequest.DRAFT object.

Possible errors

org.freedesktop.Telepathy.Error.InvalidArgument
The Preferred_Handler is syntactically invalid or does not start with org.freedesktop.Telepathy.Client., the Account does not exist, or one of the Requested_Properties is invalid

Cancel ( o: Request ) → nothing

Cancel a 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.

Parameters

Requesto
The channel request to be cancelled.

Signals:

Failed ( o: Request, s: Error, s: Message )

The channel request has failed. It is no longer present, and further methods must not be called on it.

Parameters

Requesto
The channel request.
Errors (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.

Messages
If the first argument of the D-Bus error message was a string, that string. Otherwise, an empty string.

Succeeded ( o: Request )

The channel request has succeeded. It is no longer present, and further methods must not be called on it.

Parameters

Requesto
The channel request.

Interface has no Telepathy properties.

Interface has no D-Bus core properties.

com.nokia.Account.Interface.Compat

Implementations of this interface must also implement:

The Compat interface holds properties necessary for maintaining the libmissioncontrol compatible layer.

Methods:

SetHasBeenOnline ( ) → nothing

Force MC to believe that this account has been put online successfully at some point in the past.

Signals:

CompatPropertyChanged ( a{sv}: Properties )

The values of one or more properties on this interface may have changed.

Parameters

Propertiesa{sv}
A map from property names in this namespace (e.g. SecondaryVCardFields) to values. Properties whose values have not changed SHOULD be omitted, but this need not be done.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Profiles, read/write

The name of the profile.

AvatarFiles, read-only

The location of the avatar.

SecondaryVCardFieldsas, read/write

List of secondary VCard fields.

com.nokia.Account.Interface.Conditions

Implementations of this interface must also implement:

The Conditions interface specifies under what conditions an account can be put online. When the conditions are met and the ConnectAutomatically property on the account is set to True, then the account will automatically try to connect. On the other hand, if the conditions are not met, the account won't attempt to connect, not even if requested so.

The main goal is to bind accounts to connectivity: most TCP and UDP based protocols require a network route to be present, while link-local does not; some protocol might be specifically designed to work only over bluetooth, in which case we don't want to attempt a connection if bluetooth is not available. Then, some accounts might work only in certain VPNs.

There is also the case of user preferences: one might want to activate a certain account only when he is at home (in that case, he could set a rule on the network ESSID) or when he is not at work (this requires the possibility of negating rules).

The proposed format of a rule is (name, value), where name is a string (which is typically a connectivity parameter, such as "ip-address", "vpn-name", "essid", maybe prefixed with some namespacing convention) and value is the value the parameter must assume for the rule to be met. The value, it will be specified as a string, but we want to be able to specify multiple alternatives (for instance a rule might be "connect if ESSID is HOME or WORK"), as well as negative matches. The proposed syntax is simple yet expressive enough.

Conditions consists of a list of rules, which take the form of a struct (name, value), where:

Interface has no methods.

Interface has no signals.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Conditiona{ss} (String_String_Map), read/write

The condition is a list of rules, consisting of a name and of a value, both strings. The syntax for the value is:

value ::= [logic] (":" singlevalue | "[" listvalue)
logic ::= ("!" | <possibly other operators>)
singlevalue ::= <possibly any ASCII string>
listvalue ::= separator list
separator ::= <any non-blank ASCII character>
list ::= singlevaluenonsep (separator singlevaluenonsep)*
singlevaluenonsep ::= <ASCII string not containing the separator character>

Some examples of values:

:my_essid_name
!:my_essid_name
[,my_essid_name,his_essid_name
![,my_essid_name,his_essid_name

Questions:

  • Should it be a(ss) or a{ss}?
  • Should we specify namespacing rules for the name?
  • Should we allow wildcards in the values?

com.nokia.Account.Interface.Stats

Interface has no methods.

Signals:

StatsChanged ( a{sv}: Properties )

Emitted when a property in this interface changes.

Parameters

Propertiesa{sv}
A map from property names in this namespace (e.g. Nickname) to values. Properties whose values have not changed SHOULD be omitted, but this need not be done.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

ChannelCounta{su} (Channel_Count_Map), read-only
A dictionary of channel types and their count.

Mapping types

Channel_Count_Map − a{ s: Key → u: Value }

A mapping from strings representing channel types to their usage count

Members

Keys
(undocumented)
Valueu
(undocumented)

org.freedesktop.Telepathy.AccountManager

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.

Methods:

CreateAccount ( s: Connection_Manager, s: Protocol, s: Display_Name, a{sv}: Parameters, a{sv}: Properties ) → o

Request the creation of a new Account. The account manager SHOULD NOT allow invalid accounts to be created.

Parameters

Connection_Managers (Connection_Manager_Name)
The name of the connection manager, e.g. "salut".
Protocols (Protocol)
The protocol, e.g. "local-xmpp".
Display_Names
The initial value of the new account's DisplayName property. The account manager SHOULD modify this to make it unique if an Account already exists with the same display name, for instance by appending a number or the 'account' parameter. Account manager implementations SHOULD accept an empty string, but account editing user interfaces should avoid passing an empty string for this parameter.
The account creation UI may ask the user for a name for the new account. If the author of the UI chooses not to do this, the account creation UI is better able to suggest a default display name because it has protocol-specific knowledge which the account manager does not. The account manager always knows the complete list of accounts so it can easily tell whether it should append something to the display name to avoid presenting two identically-named accounts to the user.
Parametersa{sv}
Initial parameter values, as would be passed to RequestConnection.
Propertiesa{sv} (Qualified_Property_Value_Map)

The values of any other properties to be set immediately on the new Account.

Only the properties mentioned in SupportedAccountProperties are acceptable here. In particular, the DisplayName and Parameters properties are never allowed here, since they are set using the other arguments to this method.

Account manager implementations SHOULD support creating accounts with an empty value for this argument.

Returns

Accounto
The new Account.

Possible errors

org.freedesktop.Telepathy.Error.NotImplemented

The Connection_Manager is not installed or does not implement the given Protocol, or one of the properties in the Properties argument is unsupported.

org.freedesktop.Telepathy.Error.InvalidArgument

The Parameters provided omit a required parameter or provide unsupported parameter, or the type of one of the Parameters or Properties is inappropriate.

Signals:

AccountRemoved ( o: Account )

The given account has been removed.
This is effectively change notification for the valid and invalid accounts lists. On emission of this signal, the Account indicated will no longer be present in either of the lists.

Parameters

Accounto
An Account, which must not be used any more.

AccountValidityChanged ( o: Account, b: Valid )

The validity of the given account has changed. New accounts are also indicated by this signal, as an account validity change (usually to True) on an account that did not previously exist.
This is effectively change notification for the valid and invalid accounts lists.

Parameters

Accounto
An Account.
Validb
True if the account is now valid.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Interfacesas (DBus_Interface[]), read-only
A list of the interfaces provided by the account manager object.
ValidAccountsao, read-only
A list of the valid (complete, usable) accounts. Change notification is via AccountValidityChanged.
This split between valid and invalid accounts makes it easy to ignore the invalid ones. The only things that should be manipulating invalid accounts are account-editing UIs, which might be able to rescue them.
InvalidAccountsao, read-only
A list of incomplete or otherwise unusable accounts. Change notification is via AccountValidityChanged.
SupportedAccountPropertiesas (DBus_Qualified_Member[]), read-only

A list of the fully qualified names of properties that can be set via the Properties argument to CreateAccount when an account is created.

Examples of good properties to support here include Icon, Enabled, Nickname, AutomaticPresence, ConnectAutomatically, RequestedPresence and Avatar.

Examples of properties that would make no sense here include Valid, Connection, ConnectionStatus, ConnectionStatusReason, CurrentPresence and NormalizedName.

This property MUST NOT include include the DisplayName and Parameters properties, which are set using separate arguments.

This property MAY include the names of properties that, after account creation, will be read-only: this indicates that the property can be set at account creation but not changed later.

For example, an account manager might support migration tools that use this to preserve the HasBeenOnline property, even though that property is usually read-only.

com.nokia.AccountManager.Interface.Query

Implementations of this interface must also implement:

The Query interface provides a convienient way for clients to retrieve a subset of the accounts satisfying certain conditions.

This is basically the same API proposed by Zdra

Methods:

FindAccounts ( a{sv}: params ) → ao

Find all accounts which match the search query.

An empty parameter should return all accounts

Parameters

paramsa{sv} (String_Variant_Map)

The search query data. The keys can be any Connection Manager parameter (in which case they must be prepended with the string "param-"), any readable Account property (in the form Interface.PropertyName) or any of these special keys:

  • s: Manager
  • s: Protocol
  • u: RequestedPresence
  • s: RequestedStatus
  • u: CurrentPresence
  • s: CurrentStatus

Returns

accountsao
The array of account objects.

Interface has no signals.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Keywordsas, read-only
A list of the special keywords recognized by the FindAccounts method.
It's likely that some new keywords will be added later, or that different implementation of this interface will support a different set of keywords; in such a scenario it seems proper to inform the client about supported keywords. But I'm not sure this is really needed.

org.freedesktop.Telepathy.Client

This interface is not yet final 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.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Interfacesas (DBus_Interface[]), read-only

A 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.

org.freedesktop.Telepathy.Client.Approver

This interface is not yet final 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 are clients that notify the user that new channels have been created by a contact, and allow the user to accept or reject those channels. The new channels are represented by a ChannelDispatchOperation object, which is passed to the AddDispatchOperation method.

For instance, Empathy's tray icon, or the answer/reject window seen when a Maemo device receives a VoIP call, should be Approvers.

Approvers 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 dispatch operation with a particular channel handler by calling the HandleWith method. Approvers can also attempt to Claim channels; if this succeeds, the approver may handle the channels itself (if it is also a Handler), or close the channels in order to reject them.

At the D-Bus level, there is no "reject" operation: approvers wishing to reject channels SHOULD call the Claim method, then (if it succeeds) close the channels in any way they see fit.

The first approver to reply gets its decision acted on; any other approvers that reply at approximately 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)

Methods:

AddDispatchOperation ( a(oa{sv}): Channels, o: DispatchOperation, a{sv}: Properties ) → nothing

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 an approver returns an error from this method, the approver is assumed to be faulty.

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.

Processes that aren't approvers (or don't at least ensure that there is some approver) probably shouldn't be making connections anyway, so there should always be at least one approver running.

Parameters

Channelsa(oa{sv}) (Channel_Details[])

The initial value of the ChannelDispatchOperation.Channels property, containing the Channels to be dispatched and their properties.

This can't be signalled to the approver through the Properties parameter of this method, because Channels is not an immutable property.

This argument always contains all of the channels in the channel dispatch operation, even if not all of them actually match the ApproverChannelFilter.

This seems the least bad way to handle such a situation; see the discussion on bug #21090.

The actual channels to be dispatched may reduce as channels are closed: this is signalled by ChannelDispatchOperation.ChannelLost.

Approvers SHOULD connect to ChannelLost and ChannelDispatchOperation.Finished. (if desired) before returning from AddDispatchOperation, since those signals are guaranteed not to be emitted until after all AddDispatchOperation calls have returned (with success or failure) or timed out.

DispatchOperationo

The ChannelDispatchOperation to be processed.

Propertiesa{sv} (Qualified_Property_Value_Map)
Properties of the channel dispatch operation. This MUST NOT include properties that could change, SHOULD include as many properties as possible given that constraint, and MUST include at least the Account, Connection and PossibleHandlers properties.

Interface has no signals.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

ApproverChannelFilteraa{sv} (Channel_Class[]), read-only

A specification of the channels in which this approver is interested. The AddDispatchOperation method should be called by the channel dispatcher whenever at least one of the channels in a channel dispatch operation matches this description.

This property works in exactly the same way as the Client.Observer.ObserverChannelFilter property. In particular, it cannot change while the approver process continues to own the corresponding Client bus name.

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.

org.freedesktop.Telepathy.Client.Handler

This interface is not yet final 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:

Handlers are the user interface for a channel. They turn an abstract Telepathy channel into something the user wants to see, like a text message stream or an audio and/or video call.

For its entire lifetime, each channel on a connection known to the channel dispatcher is either being processed by the channel dispatcher, or being handled by precisely one Handler.

Because each channel is only handled by one Handler, handlers may perform actions that only make sense to do once, such as acknowledging Text messages, doing the actual streaming for StreamedMedia channels with the MediaSignalling interface, or transferring the file in FileTransfer channels.

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)

Methods:

HandleChannels ( o: Account, o: Connection, a(oa{sv}): Channels, ao: Requests_Satisfied, t: User_Action_Time, a{sv}: Handler_Info ) → nothing

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, the handler is assumed to have failed or crashed, and the channel dispatcher MUST recover in an implementation-specific way; it MAY attempt to dispatch the channels to another handler, or close the channels.

If closing the channels, 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.

After HandleChannels returns successfully, the client process is considered to be responsible for the channel until it its unique name disappears from the bus.

If a process has multiple Client bus names - some temporary and some long-lived - and drops one of the temporary bus names in order to reduce the set of channels that it will handle, any channels that it is already handling should remain unaffected.

Parameters

Accounto
The Account with which the channels are associated. The well-known bus name to use is that of the AccountManager.
Connectiono
The Connection with which the channels are associated. The well-known bus name to use can be derived from this object path by removing the leading '/' and replacing all subsequent '/' by '.'.
Channelsa(oa{sv}) (Channel_Details[])
The channels and their immutable properties. Their well-known bus name is the same as that of the Connection.
Requests_Satisfiedao

The requests satisfied by these channels.

If the handler implements Requests, this tells it that these channels match previous AddRequest calls that it may have received.

There can be more than one, if they were EnsureChannel requests.

User_Action_Timet
The time at which user action occurred, or 0 if this channel is to be handled for some reason not involving user action. Handlers SHOULD use this for focus-stealing prevention, if applicable.
Handler_Infoa{sv}

Additional information about these channels. No keys are currently defined.

If keys are defined for this dictionary, all will be optional; handlers MAY safely ignore any entry in this dictionary.

Interface has no signals.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

HandlerChannelFilteraa{sv} (Channel_Class[]), read-only

A 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.ObserverChannelFilter property. In particular, it cannot change while the handler process continues to own the corresponding Client bus name.

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.

BypassApprovalb, read-only

If 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)

HandledChannelsao, read-only

A list of the channels that this process 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.

The value of this property SHOULD be the same for all Client instances that share a unique bus name, and SHOULD include all channels that are being handled, even if they were conceptually handled by a different Client instance.

Otherwise, when a process released a temporary Client name, channels that it handled because of that Client name would no longer be state-recoverable.

org.freedesktop.Telepathy.Client.Interface.Requests

This interface is not yet final 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 can be implemented by a Handler to be notified about requests for channels that it is likely to be asked to handle.

Added in version 0.17.23. (as a draft; functionality moved from Handler)

Methods:

AddRequest ( o: Request, a{sv}: Properties ) → nothing

Called by the ChannelDispatcher to indicate that channels have been requested, and that if the request is successful, they will probably be handled by this Handler. The ChannelDispatcher SHOULD only call this method on one handler per request.

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.

The use of "probably" is because you can't necessarily tell from a channel request which handler will handle particular channels. A reasonable heuristic would be to match the request against the HandlerChannelFilter, and respect the preferred handler (if any).

If the request succeeds and is given to the expected Handler, the Requests_Satisfied parameter to HandleChannels can be used to match the channel to a previous AddRequest call.

This lets the UI direct the channels to the window that it already opened.

If the request fails, the expected handler is notified by the channel dispatcher calling its RemoveRequest method.

This lets the UI close the window or display the error.

The channel dispatcher SHOULD remember which handler was notified, and if the channel request succeeds, it SHOULD dispatch the channels to the expected handler, unless the channels do not match that handler's HandlerChannelFilter. If the channels are not dispatched to the expected handler, the handler that was expected is notified by the channel dispatcher calling its RemoveRequest method with the NotYours error.

Expected handling is for the UI to close the window it previously opened.

Handlers SHOULD NOT return an error from this method; errors returned from this method SHOULD NOT alter the channel dispatcher's behaviour.

Calls to this method are merely a notification.

Parameters

Requesto
The ChannelRequest object, which MUST have been returned by CreateChannel or EnsureChannel before this method is called.
See those methods for the rationale of this ordering.
Propertiesa{sv} (Qualified_Property_Value_Map)
Some of the properties of the ChannelRequest. To avoid race conditions, this dictionary MUST NOT include properties whose values could subsequently change. It SHOULD include as many properties as possible, given that constraint. In particular, the properties Requests and UserActionTime MUST be included.

RemoveRequest ( o: Request, s: Error, s: Message ) → nothing

Called by the ChannelDispatcher to indicate that a request previously passed to AddRequest has failed and should be disregarded.

Handlers SHOULD NOT return an error from this method; errors returned from this method SHOULD NOT alter the channel dispatcher's behaviour.

Calls to this method are merely a notification.

Parameters

Requesto
The request that failed.
Errors (DBus_Error_Name)

The name of the D-Bus error with which the request failed.

If this is org.freedesktop.Telepathy.Error.NotYours, this indicates that the request succeeded, but all the resulting channels were given to some other handler.

Messages
Any message supplied with the D-Bus error.

Interface has no signals.

Interface has no Telepathy properties.

Interface has no D-Bus core properties.

org.freedesktop.Telepathy.Client.Observer

This interface is not yet final 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 a collection of new channels is 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 some of the channels.

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.

Because it might take time for an observer to become ready (for instance, a Text logger needs to wait until pending messages have been downloaded), the channel dispatcher must wait (up to some timeout) for all observers to return from ObserveChannels before letting anything destructive happen. Destructive things (e.g. acknowledging messages) are defined to be done by handlers, therefore HandleWith and Claim aren't allowed to succeed until all observers are ready.

Added in version 0.17.12. (as a draft)

Methods:

ObserveChannels ( o: Account, o: Connection, a(oa{sv}): Channels, o: Dispatch_Operation, ao: Requests_Satisfied, a{sv}: Observer_Info ) → nothing

Called by the channel dispatcher when channels in which the observer has registered an interest are announced in a NewChannels signal.

If the same NewChannels signal announces some channels that match the filter, and some that do not, then only a subset of the channels (those that do match the filter) are passed to this method.

If the channel dispatcher will split up the channels from a single NewChannels signal and dispatch them separately (for instance because no installed Handler can handle all of them), it will call ObserveChannels several times.

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 ObserveChannels, text channel handler gets HandleChannels channel handler starts up faster and acknowledges messages, logger never sees those messages.

The channel dispatcher SHOULD NOT change its behaviour based on whether this method succeeds or fails: there are no defined D-Bus errors for this method, and if it fails, this only indicates that an Observer is somehow broken.

The expected error response in the channel dispatcher is to log a warning, and otherwise continue as though this method had succeeded.

Parameters

Accounto
The Account with which the channels are associated. The well-known bus name to use is that of the AccountManager.
Connectiono
The Connection with which the channels are associated. The well-known bus name to use can be derived from this object path by removing the leading '/' and replacing all subsequent '/' by '.'.
Channelsa(oa{sv}) (Channel_Details[])
The Channels and their properties. Their well-known bus names are all the same as that of the Connection.
Dispatch_Operationo

The path to the ChannelDispatchOperation for these channels, or the special value '/' if there is no ChannelDispatchOperation (because the channels were requested, not incoming).

If the Observer calls Claim or HandleWith on the dispatch operation, it MUST be careful to avoid deadlock, since these methods cannot return until the Observer has returned from ObserveChannels.

This allows an Observer to Claim a set of channels without having to match up calls to this method with calls to AddDispatchOperation.

Requests_Satisfiedao
The requests satisfied by these channels.
If the same process is an Observer and a Handler, it can be useful to be given this information as soon as possible (it will also be passed to Handler.HandleChannels).
Observer_Infoa{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.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

ObserverChannelFilteraa{sv} (Channel_Class[]), read-only

A 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.

Only certain D-Bus types have useful semantics for matching like this, so only certain types are allowed:

Integers of all sizes, including byte (y, n, q, i, u, x, t)
Matched by numeric value, regardless of type (e.g. 42 as a 16-bit signed integer 'n' is considered equal to 42 as a 32-bit unsigned integer 'u')
Booleans (b)
Matched by equality in the obvious way; not considered equal to any other type
Strings (s)
Matched by equality in the obvious way; not considered equal to any other type
Object paths (o)
Matched by equality in the obvious way; not considered equal to any other type

This property never changes while the observer process owns its Client bus name. 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.

Not allowing this property to change is a simplification, particularly for activatable processes (we reject the possibility that a process with a .client file, when activated, has a filter that differs from what its .client file said).

If an Observer wants to add extra channels to its list of interests at runtime, it can register an additional Client bus name (for instance, the org.freedesktop.Telepathy.Client.Empathy process with unique name :1.42 could additionally register org.freedesktop.Telepathy.Client.Empathy._1_42) with additional filters. To remove those filters, it can release the bus name; it could even re-claim the bus name immediately, with different filters.

The same principle is applied to Approvers and Handlers.

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]
Interfaces=org.freedesktop.Telepathy.Client.Observer;

[org.freedesktop.Telepathy.Client.Observer.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.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

org.freedesktop.Telepathy.ChannelDispatcher

This interface is not yet final 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:

Observer

Observers monitor the creation of new channels. This functionality can be used for things like message logging. All observers are notified simultaneously.

Approver
p

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.

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.

Methods:

CreateChannel ( o: Account, a{sv}: Requested_Properties, x: User_Action_Time, s: Preferred_Handler ) → o

Start a request to create a channel. This initially just creates a ChannelRequest 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.Proceed is called, at which point ChannelRequest.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.

Parameters

Accounto
The Account for which the new channel is to be created.
Requested_Propertiesa{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_Timex (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_Handlers (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 and the handler has the Requests interface, 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.

This is copied to the ChannelRequest that is returned, as the PreferredHandler property.

Returns

Requesto
A ChannelRequest object.

Possible errors

org.freedesktop.Telepathy.Error.InvalidArgument
The Preferred_Handler is syntactically invalid or does not start with org.freedesktop.Telepathy.Client., the Account does not exist, or one of the Requested_Properties is invalid

EnsureChannel ( o: Account, a{sv}: Requested_Properties, x: User_Action_Time, s: Preferred_Handler ) → o

Start a request to ensure that a channel exists, creating it if necessary. This initially just creates a ChannelRequest 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.Proceed is called, at which point ChannelRequest.Failed is emitted with an appropriate error.

The rationale is as for CreateChannel.

Parameters

Accounto
The Account for which the new channel is to be created.
Requested_Propertiesa{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_Timex (Unix_Timestamp64)

The time at which user action occurred, or 0 if this channel request is for some reason not involving user action.

This parameter is used in the same way as the corresponding parameter to CreateChannel.

Preferred_Handlers (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 behaviour and rationale are the same as for the corresponding parameter to CreateChannel, except as noted here.

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.

Returns

Requesto
A ChannelRequest object.

Possible errors

org.freedesktop.Telepathy.Error.InvalidArgument
The Preferred_Handler is syntactically invalid or does not start with org.freedesktop.Telepathy.Client., the Account does not exist, or one of the Requested_Properties is invalid

Interface has no signals.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Interfacesas (DBus_Interface[]), read-only
A list of the extra interfaces provided by this channel dispatcher.

org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList

This interface is not yet final 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.

Signals:

NewDispatchOperation ( o: Dispatch_Operation, a{sv}: Properties )

Emitted when a dispatch operation is added to DispatchOperations.

Parameters

Dispatch_Operationo
The dispatch operation that was created.
Propertiesa{sv} (Qualified_Property_Value_Map)
The same properties that would appear in the Properties member of Dispatch_Operation_Details.

DispatchOperationFinished ( o: Dispatch_Operation )

Emitted when a dispatch operation finishes (i.e. exactly once per emission of ChannelDispatchOperation.Finished).
Strictly speaking this is redundant with ChannelDispatchOperation.Finished, but it provides full change-notification for the DispatchOperations property.

Parameters

Dispatch_Operationo
The dispatch operation that was closed.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

DispatchOperationsa(oa{sv}) (Dispatch_Operation_Details[]), read-only

The list of ChannelDispatchOperation objects currently being processed. Change notification is via the NewDispatchOperation and DispatchOperationFinished signals.

Structure types

Dispatch_Operation_Details − ( o: Channel_Dispatch_Operation, a{sv}: Properties )

Details of a channel dispatch operation.

In bindings that need a separate name, arrays of Dispatch_Operation_Details should be called Dispatch_Operation_Details_List.

Members

Channel_Dispatch_Operationo
The object path of the ChannelDispatchOperation.
Propertiesa{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:

org.freedesktop.Telepathy.ChannelRequest

This interface is not yet final 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.CreateChannel for rationale for ChannelRequest being a separate object.

A channel request can be cancelled by any client (not just the one that requested it). This means that the ChannelDispatcher will Close the resulting channel, or refrain from requesting it at all, rather than dispatching it to a handler.

Methods:

Proceed ( ) → nothing

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.

Possible errors

org.freedesktop.Telepathy.Error.NotAvailable
This method has already been called, so it is no longer available. Stop calling it.

Cancel ( ) → nothing

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.Error.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.

Signals:

Failed ( s: Error, s: Message )

The channel request has failed. It is no longer present, and further methods must not be called on it.

Parameters

Errors (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.

Messages
If the first argument of the D-Bus error message was a string, that string. Otherwise, an empty string.

Succeeded ( )

The channel request has succeeded. It is no longer present, and further methods must not be called on it.

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Accounto, read-only
The Account on which this request was made. This property cannot change.
UserActionTimex (Unix_Timestamp64), read-only

The 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.

PreferredHandlers (DBus_Well_Known_Name), read-only

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 property is set when the channel request is created, and can never change.

Requestsaa{sv} (Qualified_Property_Value_Map[]), read-only

An 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.

Interfacesas (DBus_Interface[]), read-only
A list of the extra interfaces provided by this channel request. This property cannot change.

org.freedesktop.Telepathy.ChannelDispatchOperation

This interface is not yet final 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 batch of unrequested channels being announced to client Approver 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 Handlers 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.

If no handler at all can handle a channel, the channel dispatcher SHOULD terminate that channel instead of creating a channel dispatcher for it. It is RECOMMENDED that the channel dispatcher closes the channels using Channel.Interface.Destroyable.Destroy if supported, or Channel.Close otherwise. As a special case, the channel dispatcher SHOULD NOT close ContactList channels, and if Close fails, the channel dispatcher SHOULD ignore that channel.

ContactList channels are strange. We hope to replace them with something better, such as an interface on the Connection, in a future version of this specification.

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 all of 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.

Methods:

HandleWith ( s: Handler ) → nothing

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.

Parameters

Handlers (DBus_Bus_Name)

The well-known bus name (starting with org.freedesktop.Telepathy.Client.) of the channel handler that should handle the channel, or the empty string if the client has no preferred channel handler.

Possible errors

org.freedesktop.Telepathy.Error.InvalidArgument
The selected handler is non-empty, but is not a syntactically correct DBus_Bus_Name or does not start with "org.freedesktop.Telepathy.Client.".
org.freedesktop.Telepathy.Error.NotAvailable
The selected handler is temporarily unable to handle these channels.
org.freedesktop.Telepathy.Error.NotImplemented
The selected handler is syntactically correct, but will never be able to handle these channels (for instance because the channels do not match its HandlerChannelFilter, or because HandleChannels raised NotImplemented).
org.freedesktop.Telepathy.Error.NotYours
At the time that HandleWith was called, this dispatch operation was processing an earlier call to HandleWith. The earlier call has now succeeded, so some Handler nominated by another approver is now responsible for the channels. In this situation, the second call to HandleWith MUST NOT return until the first one has returned successfully or unsuccessfully, and if the first call to HandleChannels fails, the channel dispatcher SHOULD try to obey the choice of Handler made by the second call to HandleWith.

Claim ( ) → nothing

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 HandledChannels 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 - or to call Channel.Interface.Destroyable.Destroy if the destructive behaviour of that method is desired.

Similarly, an Approver for StreamedMedia channels can close the channel with a reason (e.g. "busy") if desired. The channel dispatcher, which is designed to have no specific knowledge of particular channel types, can't do that.

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)

Possible errors

org.freedesktop.Telepathy.Error.NotYours
At the time that Claim was called, this dispatch operation was processing a call to HandleWith which has now succeeded, so some Handler nominated by another approver is now responsible for the channel.

Signals:

ChannelLost ( o: Channel, s: Error, s: Message )

A channel has closed before it could be claimed or handled. If this is emitted for the last remaining channel in a channel dispatch operation, it MUST immediately be followed by Finished.

This signal MUST NOT be emitted until all Approvers that were invoked have returned (successfully or with an error) from their AddDispatchOperation method.

This means that Approvers can connect to the ChannelLost signal in a race-free way. Non-approver processes that discover a channel dispatch operation in some way (such as observers) will have to follow the usual "connect to signals then recover state" model - first connect to ChannelLost and Finished, then download Channels (and on error, perhaps assume that the operation has already Finished).

Parameters

Channelo
The Channel that closed.
Errors (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.Error.NotAvailable MAY be used as a fallback; this means that this error SHOULD NOT be given any more specific meaning.

Messages
A string associated with the D-Bus error.

Finished ( )

Emitted when this dispatch operation finishes. The dispatch operation is no longer present and further methods must not be called on it.

Approvers that have a user interface SHOULD stop notifying the user about the channels in response to this signal; they MAY assume that on errors, they would have received ChannelLost first.

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.

This signal MUST NOT be emitted until all Approvers that were invoked have returned (successfully or with an error) from their AddDispatchOperation method.

This means that Approvers can connect to the ChannelLost signal in a race-free way. Non-approver processes that discover a channel dispatch operation in some way (such as observers) will have to follow the usual "connect to signals then recover state" model - first connect to ChannelLost and Finished, then download Channels (and on error, perhaps assume that the operation has already Finished).

Interface has no Telepathy properties.

D-Bus core Properties:

Accessed using the org.freedesktop.DBus.Properties interface.

Interfacesas (DBus_Interface[]), read-only
A list of the extra interfaces provided by this channel dispatch operation. This property cannot change.
Connectiono, read-only
The Connection with which the Channels are associated. The well-known bus name to use can be derived from this object path by removing the leading '/' and replacing all subsequent '/' by '.'. This property cannot change.
Accounto, read-only
The Account with which the Connection and Channels are associated. This property cannot change.
Channelsa(oa{sv}) (Channel_Details[]), read-only
The Channels to be dispatched, and their properties. Change notification is via the ChannelLost signal (channels cannot be added to this property, only removed).
PossibleHandlersas (DBus_Well_Known_Name[]), read-only
The well known bus names (starting with org.freedesktop.Telepathy.Client.) of the possible Handlers for these channels. The channel dispatcher MUST place the most preferred handlers first, according to some reasonable heuristic. As a result, approvers SHOULD use the first handler by default. The heuristic used to prioritize handlers SHOULD give a higher priority to handlers that are already running.
If, for instance, Empathy and Kopete have similar functionality, and Empathy is running, we should prefer to send channels to it rather than launching Kopete via service activation.

org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT

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)

Methods:

SetSelfCapabilities ( aa{sv}: caps ) → nothing

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.

Parameters

capsaa{sv} (String_Variant_Map[])
An array of channel classes to replace to the list of what the connection can handle. If you include optional properties, they may not get advertised. The given properties are matched to the mandatory properties.

Possible errors

org.freedesktop.Telepathy.Error.NetworkError
(Undocumented.)
org.freedesktop.Telepathy.Error.Disconnected
(Undocumented.)

GetContactCapabilities ( au: handles ) → a{ua(a{sv}as)}

Returns an array of enhanced capabilities for the given contact handles.

Parameters

handlesau (Contact_Handle[])

An array of contact handles for this connection.

The handle zero MUST NOT be included in the request.

Returns

Contact_Capabilitiesa{ua(a{sv}as)} (Contact_Capabilities_Map_1)
An array of structures containing:
  • a dictionary mapping the channel properties to their values.
  • an array of additional allowed properties

Possible errors

org.freedesktop.Telepathy.Error.Disconnected
(Undocumented.)
org.freedesktop.Telepathy.Error.InvalidHandle
The handle does not represent a contact. Zero is always invalid.

Signals:

ContactCapabilitiesChanged ( a{ua(a{sv}as)}: caps )

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.

Parameters

capsa{ua(a{sv}as)} (Contact_Capabilities_Map_1)
All the capabilities of the contacts

Interface has no Telepathy properties.

Interface has no D-Bus core properties.

Mapping types

Contact_Capabilities_Map_1 − a{ u: Key → a(a{sv}as): Value }

A mapping from contact handle to their capabilities.

In bindings that need a separate name, arrays of Contact_Capabilities_Map_1 should be called Contact_Capabilities_Map_1_List.

Members

Keyu (Contact_Handle)
A contact handle.
Valuea(a{sv}as) (Requestable_Channel_Class[])
The contact capabilities.

org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities

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 UpdateCapabilities method.

XMPP is a major user of this interface: XMPP contacts will not, in general, be callable using VoIP unless they advertise suitable Jingle capabilities.

Many other protocols also have some concept of capability flags, which this interface exposes in a protocol-independent way.

Added in version 0.17.28. (as stable API)

Methods:

UpdateCapabilities ( a(saa{sv}as): Handler_Capabilities ) → nothing

Alter the connection's advertised capabilities to include the intersection of the given clients' capabilities with what the connection manager is able to implement.

On connections managed by the ChannelDispatcher, processes other than the ChannelDispatcher SHOULD NOT call this method, and the ChannelDispatcher SHOULD use this method to advertise the capabilities of all the registered Client.Handler implementations.On connections not managed by the ChannelDispatcher, clients MAY use this method directly, to indicate the channels they will handle and the extra capabilities they have.

Upon a successful invocation of this method, the connection manager will only emit the ContactCapabilitiesChanged signal for the user's SelfHandle if, in the underlying protocol, the new 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.

This method MAY be called on a newly-created connection while it is still in the DISCONNECTED state, to request that when the connection connects, it will do so with the appropriate capabilities. Doing so MUST NOT fail.

Parameters

Handler_Capabilitiesa(saa{sv}as) (Handler_Capabilities[])
The capabilities of one or more clients. For each client in the given list, any capabilities previously advertised for the same client name are discarded, then replaced by the capabilities indicated. As a result, if a client becomes unavailable, this method SHOULD be called with a Handler_Capabilities structure containing its name, an empty list of channel classes, and an empty list of capabilities. When this is done, the connection manager SHOULD free all memory associated with that client name.
This method takes a list of clients so that when the channel dispatcher first calls it (with a list of all the Handlers that are initially available), the changes can be made atomically, with only one transmission of updated capabilities to the network. Afterwards, the channel dispatcher will call this method with a single-element list every time a Handler becomes available or unavailable.
The connection manager MUST ignore any channel classes and client capabilities for which there is no representation in the protocol or no support in the connection manager.

Possible errors

org.freedesktop.Telepathy.Error.NetworkError
(Undocumented.)

GetContactCapabilities ( au: handles ) → a{ua(a{sv}as)}

Returns an array of enhanced capabilities for the given contact handles.

Parameters

handlesau (Contact_Handle[])

An array of contact handles for this connection.

The handle zero MUST NOT be included in the request.

Returns

Contact_Capabilitiesa{ua(a{sv}as)} (Contact_Capabilities_Map)
An array of structures containing:
  • a dictionary mapping the channel properties to their values.
  • an array of additional allowed properties

Possible errors

org.freedesktop.Telepathy.Error.Disconnected
(Undocumented.)
org.freedesktop.Telepathy.Error.InvalidHandle
The handle does not represent a contact. Zero is always invalid.

Signals:

ContactCapabilitiesChanged ( a{ua(a{sv}as)}: caps )

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.

Parameters

capsa{ua(a{sv}as)} (Contact_Capabilities_Map)
All the capabilities of the contacts

Interface has no Telepathy properties.

Interface has no D-Bus core properties.

Structure types

Handler_Capabilities − ( s: Well_Known_Name, aa{sv}: Channel_Classes, as: Capabilities )

A structure representing the capabilities of a single client.

In bindings that need a separate name, arrays of Handler_Capabilities should be called Handler_Capabilities_List.

Members

Well_Known_Names (DBus_Well_Known_Name)
For implementations of the Client interface, the well-known bus name name of the client; for any other process, any other reversed domain name that uniquely identifies it.
Channel_Classesaa{sv} (String_Variant_Map[])
An array of channel classes that can be handled by this client. This will usually be a copy of the client's HandlerChannelFilter property.
Capabilitiesas (Handler_Capability_Token[])
An array of client capabilities supported by this client, to be used by the connection manager to determine what capabilities to advertise. This will usually be a copy of the client's Capabilities property.

Mapping types

Contact_Capabilities_Map − a{ u: Key → a(a{sv}as): Value }

A mapping from contact handle to their capabilities.

In bindings that need a separate name, arrays of Contact_Capabilities_Map should be called Contact_Capabilities_Map_List.

Members

Keyu (Contact_Handle)
A contact handle.
Valuea(a{sv}as) (Requestable_Channel_Class[])
The contact capabilities.

Generic types

Types defined elsewhere

Connection_Status − u
Defined by: Telepathy specification (Connection)
Connection_Status_Reason − u
Defined by: Telepathy specification (Connection)
Connection_Presence_Type − u
Defined by: Telepathy specification (Connection)
Connection_Manager_Name − s
Defined by: Telepathy specification (ConnectionManager)
Contact_Handle − u
Defined by: Telepathy specification (Connection)
Protocol − s
Defined by: Telepathy specification (ConnectionManager)
Simple_Presence − (uss)
Defined by: Telepathy specification (SimplePresence)
Conn_Mgr_Param_Flags − u
Defined by: Telepathy specification (ConnectionManager)
Requestable_Channel_Class − (a{sv}as)
Defined by: Telepathy specification (Requests)
Handler_Capability_Token − s
Defined by: Telepathy specification (Handler)

Generic types

Simple types

Unix_Timestamp − u

An unsigned 32-bit integer representing time as the number of seconds elapsed since the Unix epoch (1970-01-01T00:00:00Z)

Unix_Timestamp64 − x

A signed 64-bit integer representing time as the number of seconds elapsed since the Unix epoch (1970-01-01T00:00:00Z)

DBus_Bus_Name − s

A string representing a D-Bus bus name - either a well-known name like "org.freedesktop.Telepathy.MissionControl" or a unique name like ":1.123"

DBus_Well_Known_Name − s

A string representing a D-Bus well-known name like "org.freedesktop.Telepathy.MissionControl".

DBus_Unique_Name − s

A string representing a D-Bus unique name, such as ":1.123"

DBus_Interface − s

An ASCII string representing a D-Bus interface - two or more elements separated by dots, where each element is a non-empty string of ASCII letters, digits and underscores, not starting with a digit. The maximum total length is 255 characters. For example, "org.freedesktop.DBus.Peer".

DBus_Error_Name − s

An ASCII string representing a D-Bus error. This is syntactically the same as a DBus_Interface, but the meaning is different.

DBus_Signature − s

A string representing a D-Bus signature (the 'g' type isn't used because of poor interoperability, particularly with dbus-glib)

DBus_Member − s

An ASCII string representing a D-Bus method, signal or property name - a non-empty string of ASCII letters, digits and underscores, not starting with a digit, with a maximum length of 255 characters. For example, "Ping".

DBus_Qualified_Member − s

A string representing the full name of a D-Bus method, signal or property, consisting of a DBus_Interface, followed by a dot, followed by a DBus_Member. For example, "org.freedesktop.DBus.Peer.Ping".

Mapping types

Qualified_Property_Value_Map − a{ s: Key → v: Value }

A mapping from strings representing D-Bus properties (by their namespaced names) to their values.

In bindings that need a separate name, arrays of Qualified_Property_Value_Map should be called Qualified_Property_Value_Map_List.

Members

Keys (DBus_Qualified_Member)
A D-Bus interface name, followed by a dot and a D-Bus property name.
Valuev
The value of the property.

String_Variant_Map − a{ s: Key → v: Value }

A mapping from strings to variants representing extra key-value pairs.

Members

Keys
(undocumented)
Valuev
(undocumented)

String_String_Map − a{ s: Key → s: Value }

A mapping from strings to strings representing extra key-value pairs.

Members

Keys
(undocumented)
Values
(undocumented)

Index

Index of interfaces

Index of types