org.freedesktop.Telepathy.Account
org.freedesktop.Telepathy.Account.Interface.Avatar
com.nokia.Account.Interface.ChannelRequests
com.nokia.Account.Interface.Compat
com.nokia.Account.Interface.Conditions
com.nokia.Account.Interface.Stats
org.freedesktop.Telepathy.AccountManager
com.nokia.AccountManager.Interface.Query
org.freedesktop.Telepathy.AccountManager.Interface.Creation.DRAFT
org.freedesktop.Telepathy.Client
org.freedesktop.Telepathy.Client.Approver
org.freedesktop.Telepathy.Client.Handler
org.freedesktop.Telepathy.Client.Interface.Requests
org.freedesktop.Telepathy.Client.Observer
org.freedesktop.Telepathy.ChannelDispatcher
org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList
org.freedesktop.Telepathy.ChannelRequest
org.freedesktop.Telepathy.ChannelDispatchOperation
org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT
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
org.freedesktop.Telepathy.Error.PermissionDenied
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
Set
−
a{sv}
Unset
−
as
Reconnect_Required
−
as
org.freedesktop.Telepathy.Error.PermissionDenied
org.freedesktop.Telepathy.Error.InvalidArgument
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.
Properties
−
a{sv}
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyDisplayName
− s
, read/writeIcon
− s
, read/writeValid
− b
, read-onlyEnabled
− b
, read/writeThis property gives the users the possibility to prevent an account from being used. This flag does not change the validity of the account.
A disabled account can never be put online.
Use cases:
The AccountManager SHOULD allow this property to be set on invalid accounts, but MUST NOT attempt to put invalid accounts online even if they become Enabled.
There doesn't seem to be any good reason not to allow this.
Nickname
− s
, read/writeParameters
− a{sv}
, read-onlyA map from connection manager parameter names (as in the ConnectionManager interface) to their values. This property includes only those parameters that are stored for this account, and SHOULD only include those parameters that the user has explicitly set.
This property cannot be altered using Set() - use UpdateParameters instead.
AutomaticPresence
− (uss)
(Simple_Presence), read/writeThe presence status that this account should have if it is brought online.
Setting this property MUST NOT actually change the account's status until the next time it is (re)connected for some reason.
The Connection_Presence_Type in the structure SHOULD NOT be Offline or Unset.
ConnectAutomatically
− b
, read/writeConnection
− o
, read-onlyEither the object path of the Connection to
this account, or the special value '/'
if there is no
connection.
If this object path is not '/', the Connection's well-known bus name can be derived from this object path by removing the first '/' and replacing subsequent '/' characters with '.'.
ConnectionStatus
− u
, read-onlyConnectionStatusReason
− u
, read-onlyCurrentPresence
− (uss)
(Simple_Presence), read-onlyRequestedPresence
− (uss)
(Simple_Presence), read/writeThe requested presence for this account. When this is changed, the account manager should attempt to manipulate the connection manager to make CurrentPresence match RequestedPresence as closely as possible. It should not be saved to any sort of persistent storage.
When the account manager automatically connects an account, it must signal this by setting the RequestedPresence to the same thing as the AutomaticPresence.
NormalizedName
− s
, read-onlyThe normalized user ID of the local user on this account (i.e. the string returned when the InspectHandles method is called on the result of GetSelfHandle for an active connection).
It is unspecified whether this user ID is globally unique.
As currently implemented, IRC user IDs are only unique within the same IRCnet. On some saner protocols, the user ID includes a DNS name which provides global uniqueness.
If this value is not known yet (which will always be the case for accounts that have never been online), it will be an empty string.
It is possible that this value will change if the connection manager's normalization algorithm changes, although this SHOULD be avoided.
It's not always completely clear what normalization algorithm should be used; for instance, in Gabble, we currently use JIDs, but it would also have been reasonable to use xmpp URIs.
HasBeenOnline
− b
, read-onlyImplementations of this interface must also implement:
This interface extends the core Account interface to provide a user-settable avatar image.
The avatar could have been a property on the core Account interface, but was moved to a separate interface because it is likely to be large. This means that clients can safely use GetAll to get properties on the core Account interface without flooding the session bus with large images.
Added in version 0.17.6.
Interface has no methods.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Avatar
− (ays)
(Avatar), read/writeA struct containing avatar data marked with its MIME type.
Arrays of Avatar don't generally make sense.
Avatar_Data
−
ay
MIME_Type
−
s
Implementations of this interface must also implement:
The ChannelRequests interface provides methods to create and cancel channel requests, and signals to monitor them.
Requested_Properties
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties. This has the same semantics as the corresponding parameter to Connection.Interface.Requests.CreateChannel.
Certain properties will not necessarily make sense in this dictionary: for instance, TargetHandle can only be given if the requester is able to interact with a Connection to the desired account.
User_Action_Time
−
t
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_Handler
−
s
(DBus_Well_Known_Name)Either the well-known bus name (starting with
org.freedesktop.Telepathy.Client.
)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
acceptable. The channel dispatcher SHOULD dispatch as many as
possible of the resulting channels (ideally, all of them)
to that handler, and SHOULD remember the preferred handler
so it can try to dispatch subsequent channels in the same bundle
to the same handler.
This must be the well-known bus name, not the unique name, to ensure that all handlers do indeed have the Client API, and the Client object on the handler can be located easily.
This is partly so the channel dispatcher can call HandleChannels on it, and partly so the channel dispatcher can recover state if it crashes and is restarted.
Request
−
o
org.freedesktop.Telepathy.Error.InvalidArgument
Start a request to ensure that a channel exists, creating it if necessary.
Requested_Properties
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties. This has the same semantics as the corresponding parameter to Connection.Interface.Requests.EnsureChannel.
Certain properties will not necessarily make sense in this dictionary: for instance, TargetHandle can only be given if the requester is able to interact with a Connection to the desired account.
User_Action_Time
−
t
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_Handler
−
s
(DBus_Well_Known_Name)Either the well-known bus name (starting with
org.freedesktop.Telepathy.Client.
)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
acceptable.
This must be the well-known bus name, not the unique name, to ensure that all handlers do indeed have the Client API, and the Client object on the handler can be located easily.
This is partly so the channel dispatcher can call HandleChannels on it, and partly so the channel dispatcher can recover state if it crashes and is restarted.
If any new channels are created in response to this
request, the channel dispatcher SHOULD dispatch as many as
possible of the resulting channels (ideally, all of them)
to that handler, and SHOULD remember the preferred handler
so it can try to dispatch subsequent channels in the same bundle
to the same handler. If the requested channel already exists (that
is, Connection.Interface.Requests.EnsureChannel
returns Yours=False
) then the channel dispatcher
SHOULD re-dispatch the channel to its existing handler, and MUST
NOT dispatch it to this client (unless it is the existing handler);
the request is still deemed to have succeeded in this case.
An address book application, for example, might call EnsureChannel
to ensure that a text channel with a particular contact is
displayed to the user; it does not care whether a new channel was
made. An IM client might call EnsureChannel
in response to the user double-clicking an entry in the contact
list, with itself as the Preferred_Handler
; if the
user already has a conversation with that contact in another
application, they would expect the existing window to be
presented, rather than their double-click leading to an error
message. So the request should succeed, even if its
Preferred_Handler
is not used.
Request
−
o
org.freedesktop.Telepathy.Error.InvalidArgument
Request
−
o
The channel request has failed. It is no longer present, and further methods must not be called on it.
Request
−
o
Error
−
s
(DBus_Error_Name)The name of a D-Bus error. This can come from various sources, including the error raised by CreateChannel, or an error generated to represent failure to establish the Connection.
Message
−
s
The channel request has succeeded. It is no longer present, and further methods must not be called on it.
Request
−
o
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
Implementations of this interface must also implement:
The Compat interface holds properties necessary for maintaining the libmissioncontrol compatible layer.
Force MC to believe that this account has been put online successfully at some point in the past.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Profile
− s
, read/writeThe name of the profile.
AvatarFile
− s
, read-onlyThe location of the avatar.
SecondaryVCardFields
− as
, read/writeList of secondary VCard fields.
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:
name
is a string which names the rulevalue
is the valueInterface has no methods.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Condition
− a{ss}
(String_String_Map), read/writeThe 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:
Interface has no methods.
Properties
−
a{sv}
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ChannelCount
− a{su}
(Channel_Count_Map), read-onlyKey
−
s
Value
−
u
The account manager is a central service used to store account details.
The current account manager is defined to be the process that owns the well-known bus name org.freedesktop.Telepathy.AccountManager on the session bus. This process must export an /org/freedesktop/Telepathy/AccountManager object with the AccountManager interface.
Until a mechanism exists for making a reasonable automatic choice of AccountManager implementation, implementations SHOULD NOT register as an activatable service for the AccountManager's well-known bus name. Instead, it is RECOMMENDED that some component of the user's session will select and activate a particular implementation, and that other Telepathy-enabled programs can detect whether Telepathy is in use by checking whether the AccountManager's well-known name is in use at runtime.
Added in version 0.17.2.
Connection_Manager
−
s
(Connection_Manager_Name)Protocol
−
s
(Protocol)Display_Name
−
s
Parameters
−
a{sv}
Properties
−
a{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.
Account
−
o
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.
Account
−
o
Account
−
o
Valid
−
b
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyValidAccounts
− ao
, read-onlyInvalidAccounts
− ao
, read-onlySupportedAccountProperties
− as
(DBus_Qualified_Member[]), read-onlyA 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.
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
Find all accounts which match the search query.
An empty parameter should return all accounts
params
−
a{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:
accounts
−
ao
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Keywords
− as
, read-onlyImplementations of this interface must also implement:
The Creation interface provides methods and properties that are not yet finalized in the specs and that therefore are subject to change.
Request the creation of a new account, and sets the given properties on it.
Besides for optimization reasons, it makes sense for some properties to be set as soon as the account is created (one being the "Profile" property in the Compat interface).
Connection_Manager
−
s
(Connection_Manager_Name)Protocol
−
s
(Protocol)Display_Name
−
s
Parameters
−
a{sv}
Properties
−
a{sv}
(String_Variant_Map)The properties to be set, whose key must be in the form
Interface.PropertyName
.
Account
−
o
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
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.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyA list of the extra interfaces provided by this client. This SHOULD include at least one of Client.Observer, Client.Approver or Client.Handler.
In the .client
file, this is represented by key
"Interfaces
" in the group named after this interface.
The value of the key is a list of interface names each followed by
a semicolon (so it always ends with a semicolon unless it is empty),
i.e. a key of type "strings" as described in the Desktop Entry
specification.
This interface is 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)
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.
Channels
−
a(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.
DispatchOperation
−
o
The ChannelDispatchOperation to be processed.
Properties
−
a{sv}
(Qualified_Property_Value_Map)Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ApproverChannelFilter
− aa{sv}
(Channel_Class[]), read-onlyA specification of the channels in which this approver is interested. The AddDispatchOperation method should be called by the channel dispatcher whenever 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.
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)
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.
Account
−
o
Connection
−
o
Channels
−
a(oa{sv})
(Channel_Details[])Requests_Satisfied
−
ao
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_Time
−
t
Handler_Info
−
a{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.
Accessed using the org.freedesktop.DBus.Properties interface.
HandlerChannelFilter
− aa{sv}
(Channel_Class[]), read-onlyA specification of the channels that this channel handler can deal with. It will be offered to approvers as a potential channel handler for bundles that contain only suitable channels, or for suitable channels that must be handled separately.
This property works in exactly the same way as the Client.Observer.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.
BypassApproval
− b
, read-onlyIf true, channels destined for this handler are automatically handled, without invoking approvers.
The intended usage is to allow a client handling one channel to
pick up closely related channels. Suppose a client capable of
handling both Text and StreamedMedia,
org.freedesktop.Telepathy.Client.Empathy
, is
handling a StreamedMedia channel. That client can take a second
well-known bus name, say
org.freedesktop.Telepathy.Client.Empathy._1._42.Bundle1
,
and configure an object at
/org/freedesktop/Telepathy/Client/Empathy/_1/_42/Bundle1
with BypassApproval = TRUE,
whose HandlerChannelFilter
matches closely related Text channels by their Bundle property.
(This is use-case dis5)
HandledChannels
− ao
, read-onlyA list of the channels that this 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.
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)
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.
Request
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Called by the ChannelDispatcher to indicate that a request previously passed to AddRequest has failed and should be disregarded.
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.
Request
−
o
Error
−
s
(DBus_Error_Name)The name of the D-Bus error with which the request failed.
If this is org.freedesktop.Telepathy.Error.NotYours
,
this indicates that the request succeeded, but all the resulting
channels were given to some other handler.
Message
−
s
Interface has no signals.
Interface has no Telepathy properties.
Interface has no D-Bus core properties.
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)
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.
Account
−
o
Connection
−
o
Channels
−
a(oa{sv})
(Channel_Details[])Dispatch_Operation
−
o
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_Satisfied
−
ao
Observer_Info
−
a{sv}
Additional information about these channels. No keys are currently defined.
If keys are defined for this dictionary, all will be optional; observers MAY safely ignore any entry in this dictionary.
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
ObserverChannelFilter
− aa{sv}
(Channel_Class[]), read-onlyA specification of the channels in which this observer is interested. The ObserveChannels method should be called by the channel dispatcher whenever any of the new channels in a NewChannels signal match this description.
Only certain D-Bus types have useful semantics for matching like this, so only certain types are allowed:
This property never changes while the observer process 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
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:
Observers monitor the creation of new channels. This functionality can be used for things like message logging. All observers are notified simultaneously.
Approvers notify the user that new channels have been created, and also select which channel handler will be used for the channel, either by asking the user or by choosing the most appropriate channel handler.
Each new channel or set of channels is passed to exactly one handler as its final destination. A typical channel handler is a user interface process handling channels of a particular type.
Start a request to create a channel. This initially just creates a ChannelRequest 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.
Account
−
o
Requested_Properties
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties. This has the same semantics as the corresponding parameter to Connection.Interface.Requests.CreateChannel.
Certain properties will not necessarily make sense in this dictionary: for instance, TargetHandle can only be given if the requester is able to interact with a Connection to the desired account.
User_Action_Time
−
x
(Unix_Timestamp64)The time at which user action occurred, or 0 if this channel
request is for some reason not involving user action.
The UserActionTime
property will be set to this value, and it will eventually be
passed as the User_Action_Time
parameter of HandleChannels.
Preferred_Handler
−
s
(DBus_Well_Known_Name)Either the well-known bus name (starting with
org.freedesktop.Telepathy.Client.
)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
acceptable. The channel dispatcher SHOULD dispatch as many as
possible of the resulting channels (ideally, all of them)
to that handler, and SHOULD remember the preferred handler
so it can try to dispatch subsequent channels in the same bundle
to the same handler.
This must be the well-known bus name, not the unique name, to ensure that all handlers do indeed have the Client API, and the Client object on the handler can be located easily.
This is partly so the channel dispatcher can call HandleChannels on it, and partly so the channel dispatcher can recover state if it crashes and is restarted.
If this is a well-known bus name 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.
Request
−
o
org.freedesktop.Telepathy.Error.InvalidArgument
Start a request to ensure that a channel exists, creating it if necessary. This initially just creates a ChannelRequest 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.
Account
−
o
Requested_Properties
−
a{sv}
(Qualified_Property_Value_Map)A dictionary containing desirable properties. This has the same semantics as the corresponding parameter to Connection.Interface.Requests.EnsureChannel.
Certain properties will not necessarily make sense in this dictionary: for instance, TargetHandle can only be given if the requester is able to interact with a Connection to the desired account.
User_Action_Time
−
x
(Unix_Timestamp64)The time at which user action occurred, or 0 if this channel request is for some reason not involving user action.
This parameter is used in the same way as the corresponding parameter to CreateChannel.
Preferred_Handler
−
s
(DBus_Well_Known_Name)Either the well-known bus name (starting with
org.freedesktop.Telepathy.Client.
)
of the preferred handler for this
channel, or an empty string to indicate that any handler would be
acceptable. The 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.
Request
−
o
org.freedesktop.Telepathy.Error.InvalidArgument
Interface has no signals.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyThis interface is 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.
Emitted when a dispatch operation is added to DispatchOperations.
Dispatch_Operation
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Dispatch_Operation
−
o
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
DispatchOperations
− a(oa{sv})
(Dispatch_Operation_Details[]), read-onlyThe list of ChannelDispatchOperation objects currently being processed. Change notification is via the NewDispatchOperation and DispatchOperationFinished signals.
In bindings that need a separate name, arrays of Dispatch_Operation_Details should be called Dispatch_Operation_Details_List.
Channel_Dispatch_Operation
−
o
Properties
−
a{sv}
(Qualified_Property_Value_Map)Properties of the channel dispatch operation.
Connection managers MUST NOT include properties in this mapping if their values can change. Clients MUST ignore properties that appear in this mapping if their values can change.
The rationale is the same as for Channel_Details.
Each dictionary MUST contain at least the following keys:
This interface is 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.
Proceed with the channel request.
The client that created this object calls this method when it has connected signal handlers for Succeeded and Failed.
Clients other than the client which created the ChannelRequest MUST NOT call this method.
This method SHOULD return immediately; on success, the request might still fail, but this will be indicated asynchronously by the Failed signal.
Proceed cannot fail, unless clients have got the life-cycle of a ChannelRequest seriously wrong (e.g. a client calls this method twice, or a client that did not create the ChannelRequest calls this method). If it fails, clients SHOULD assume that the whole ChannelRequest has become useless.
org.freedesktop.Telepathy.Error.NotAvailable
Cancel the channel request. The precise effect depends on the current progress of the request.
If the connection manager has not already been asked to create a channel, then Failed is emitted immediately, and the channel request is removed.
If the connection manager has already been asked to create a channel but has not produced one yet (e.g. if Connection.Interface.Requests.CreateChannel has been called, but has not yet returned), then the ChannelDispatcher will remember that the request has been cancelled. When the channel appears, it will be closed (if it was newly created and can be closed), and will not be dispatched to a handler.
If the connection manager has already returned a channel, but the channel has not yet been dispatched to a handler then the channel dispatcher will not dispatch that channel to a handler. If the channel was newly created for this request, the channel dispatcher will close it with Close; otherwise, the channel dispatcher will ignore it. In either case, Failed will be emitted when processing has been completed.
If Failed is emitted in response to
this method, the error SHOULD be
org.freedesktop.Telepathy.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.
The channel request has failed. It is no longer present, and further methods must not be called on it.
Error
−
s
(DBus_Error_Name)The name of a D-Bus error. This can come from various sources, including the error raised by CreateChannel, or an error generated to represent failure to establish the Connection.
Message
−
s
The channel request has succeeded. It is no longer present, and further methods must not be called on it.
Interface has no Telepathy properties.
Accessed using the org.freedesktop.DBus.Properties interface.
Account
− o
, read-onlyUserActionTime
− x
(Unix_Timestamp64), read-onlyThe time at which user action occurred, or 0 if this channel request is for some reason not involving user action.
This corresponds to the _NET_WM_USER_TIME property in EWMH.
This property is set when the channel request is created, and can never change.
PreferredHandler
− s
(DBus_Well_Known_Name), read-onlyEither 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.
Requests
− aa{sv}
(Qualified_Property_Value_Map[]), read-onlyAn array of dictionaries containing desirable properties for the channel or channels to be created.
This is an array so that we could add a CreateChannels method in future without redefining the API of ChannelRequest.
This property is set when the channel request is created, and can never change.
Interfaces
− as
(DBus_Interface[]), read-onlyThis 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.
Called by an approver to accept a channel bundle and request that the given handler be used to handle it.
If successful, this method will cause the ChannelDispatchOperation object to disappear, emitting Finished.
However, this method may fail because the dispatch has already been completed and the object has already gone. If this occurs, it indicates that another approver has asked for the bundle to be handled by a particular handler. The approver MUST NOT attempt to interact with the channels further in this case, unless it is separately invoked as the handler.
Approvers which are also channel handlers SHOULD use Claim instead of HandleWith to request that they can handle a channel bundle themselves.
(FIXME: list some possible errors)
If the channel handler raises an error from HandleChannels, this method MAY respond by raising that same error, even if it is not specifically documented here.
Handler
−
s
(DBus_Bus_Name)The well-known bus name (starting with
org.freedesktop.Telepathy.Client.
) of the channel
handler that should handle the channel, or the empty string
if the client has no preferred channel handler.
org.freedesktop.Telepathy.Error.InvalidArgument
org.freedesktop.Telepathy.Client.
".
org.freedesktop.Telepathy.Error.NotAvailable
org.freedesktop.Telepathy.Error.NotImplemented
org.freedesktop.Telepathy.Error.NotYours
Called by an approver to claim channels for handling internally. If this method is called successfully, the process calling this method becomes the handler for the channel, but does not have the HandleChannels method called on it.
Clients that call Claim on channels but do not immediately close them SHOULD implement the Handler interface and its 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)
org.freedesktop.Telepathy.Error.NotYours
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).
Channel
−
o
Error
−
s
(DBus_Error_Name)The name of a D-Bus error indicating why the channel closed. If
no better reason can be found,
org.freedesktop.Telepathy.Error.NotAvailable
MAY
be used as a fallback; this means that this error SHOULD NOT be
given any more specific meaning.
Message
−
s
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.
Accessed using the org.freedesktop.DBus.Properties interface.
Interfaces
− as
(DBus_Interface[]), read-onlyConnection
− o
, read-onlyAccount
− o
, read-onlyChannels
− a(oa{sv})
(Channel_Details[]), read-onlyPossibleHandlers
− as
(DBus_Well_Known_Name[]), read-onlyThis interface is experimental and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Contact capabilities describe the channel classes which may be created with a given contact in advance of attempting to create a channel. Each capability represents a commitment by the connection manager that it will ordinarily be able to create a channel with a contact when given a request with the properties defined by the channel class.
Capabilities pertain to particular contact handles, and represent activities such as having a text chat, a voice call with the user or a stream tube of a defined type.
This interface also enables user interfaces to notify the connection manager what capabilities to advertise for the user to other contacts. This is done by using the SetSelfCapabilities method, and deals with channel property values pertaining to them which are implemented by available client processes.
Added in version 0.17.16. (as a draft)
Used by user interfaces to indicate which channel classes they are able to handle on this connection. It replaces the previous advertised channel classes by the set given as parameter.
If a channel class is unknown by the connection manager, it is just ignored. No error are returned in this case, and other known channel class are added.
Upon a successful invocation of this method, the ContactCapabilitiesChanged signal will only be emitted for the user's own handle (as returned by GetSelfHandle) by the connection manager if, in the given protocol, the given capabilities are distinct from the previous state.
The connection manager will essentially intersect the provided capabilities and the channel classes it implements. Therefore, certain properties which are never fixed for a channel class (such as the target handle, or the Parameters property of a tube channel) will almost certainly not be advertised.
caps
−
aa{sv}
(String_Variant_Map[])org.freedesktop.Telepathy.Error.NetworkError
org.freedesktop.Telepathy.Error.Disconnected
handles
−
au
(Contact_Handle[])An array of contact handles for this connection.
The handle zero MUST NOT be included in the request.
Contact_Capabilities
−
a{ua(a{sv}as)}
(Contact_Capabilities_Map)org.freedesktop.Telepathy.Error.Disconnected
org.freedesktop.Telepathy.Error.InvalidHandle
Announce that there has been a change of capabilities on the given handles. A single signal can be emitted for several contacts.
The underlying protocol can get several contacts' capabilities at the same time.
caps
−
a{ua(a{sv}as)}
(Contact_Capabilities_Map)Interface has no Telepathy properties.
Interface has no D-Bus core properties.
In bindings that need a separate name, arrays of Contact_Capabilities_Map should be called Contact_Capabilities_Map_List.
Key
−
u
(Contact_Handle)Value
−
a(a{sv}as)
(Requestable_Channel_Class[])In bindings that need a separate name, arrays of Qualified_Property_Value_Map should be called Qualified_Property_Value_Map_List.
Key
−
s
(DBus_Qualified_Member)Value
−
v
Key
−
s
Value
−
v
Key
−
s
Value
−
s
org.freedesktop.Telepathy.Account
org.freedesktop.Telepathy.Account.Interface.Avatar
com.nokia.Account.Interface.ChannelRequests
com.nokia.Account.Interface.Compat
com.nokia.Account.Interface.Conditions
com.nokia.Account.Interface.Stats
org.freedesktop.Telepathy.AccountManager
com.nokia.AccountManager.Interface.Query
org.freedesktop.Telepathy.AccountManager.Interface.Creation.DRAFT
org.freedesktop.Telepathy.Client
org.freedesktop.Telepathy.Client.Approver
org.freedesktop.Telepathy.Client.Handler
org.freedesktop.Telepathy.Client.Interface.Requests
org.freedesktop.Telepathy.Client.Observer
org.freedesktop.Telepathy.ChannelDispatcher
org.freedesktop.Telepathy.ChannelDispatcher.Interface.OperationList
org.freedesktop.Telepathy.ChannelRequest
org.freedesktop.Telepathy.ChannelDispatchOperation
org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT
Avatar
− ( ay, s )
Channel_Class
− a{ s → v }
Channel_Count_Map
− a{ s → u }
Channel_Details
− ( o, a{sv} )
Conn_Mgr_Param_Flags
− uConnection_Manager_Name
− sConnection_Presence_Type
− uConnection_Status
− uConnection_Status_Reason
− uContact_Capabilities_Map
− a{ u → a(a{sv}as) }
Contact_Handle
− uDBus_Bus_Name
− sDBus_Error_Name
− sDBus_Interface
− sDBus_Member
− sDBus_Qualified_Member
− sDBus_Signature
− sDBus_Unique_Name
− sDBus_Well_Known_Name
− sDispatch_Operation_Details
− ( o, a{sv} )
Protocol
− sQualified_Property_Value_Map
− a{ s → v }
Requestable_Channel_Class
− (a{sv}as)Simple_Presence
− (uss)String_String_Map
− a{ s → s }
String_Variant_Map
− a{ s → v }
Unix_Timestamp
− uUnix_Timestamp64
− x