Methods
| Proceed | () | → | nothing | |
| Cancel | () | → | nothing |
Signals
| Failed | (s: Error, s: Message) | |
| Succeeded | (o: Connection, a{sv}: Connection_Properties, o: Channel, a{sv}: Channel_Properties) |
Properties
| Account | o | Read only | ||
| UserActionTime | x (User_Action_Timestamp) | Read only | ||
| PreferredHandler | s (DBus_Well_Known_Name) | Read only | ||
| Requests | aa{sv} (Qualified_Property_Value_Map_List) | Read only | ||
| Interfaces | as (DBus_Interface_List) | Read only | ||
| Hints | a{sv} | Read only |
Description
A channel request is an object in the ChannelDispatcher representing an ongoing request for some channels to be created or found. They are created by methods such as CreateChannel. 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,
"im.telepathy1.ChannelDispatcher".
Rationale:
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.
Rationale:
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
- Not Available
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
im.telepathy1.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)
Parameters
- Error — s (DBus_Error_Name)
- Message — s
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.
The channel request has failed. It is no longer present, and further methods must not be called on it.
Succeeded (o: Connection, a{sv}: Connection_Properties, o: Channel, a{sv}: Channel_Properties)
Parameters
- Connection — o
- Connection_Properties — a{sv} (Qualified_Property_Value_Map)
- Channel — o
- Channel_Properties — a{sv} (Qualified_Property_Value_Map)
The Connection owning the channel.
A subset of the Connection's properties, currently unused. This parameter may be used in future.
The channel which has been created.
The same immutable properties of the Channel that would appear in a NewChannels signal.
The channel request has succeeded. It is no longer present, and further methods must not be called on it.
This signal MUST be emitted before the Succeeded signal.
Properties
Account — o
UserActionTime — x (User_Action_Timestamp)
The time at which user action occurred, or 0 if this channel request is for some reason not involving user action.
This property is set when the channel request is created, and can never change.
PreferredHandler — s (DBus_Well_Known_Name)
Either the well-known bus name (starting with
im.telepathy1.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_List)
An array of dictionaries containing desirable properties for the channel or channels to be created.
Rationale:
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_List)
Hints — a{sv}
A dictionary of metadata provided by the channel requester, which the handler and other clients MAY choose to interpret. Clients MAY choose to use platform-specific keys for their own purposes, but MUST ignore unknown keys and MUST cope with expected keys being missing. Clients SHOULD namespace hint names by having them start with a reversed domain name, in the same way as D-Bus interface names.
Rationale:
The channel dispatcher does not currently interpret any of these
hints: they are solely for communication between cooperating
clients. If hints that do affect the channel dispatcher are added in
future, their names will start with an appropriate reversed domain
name (e.g. im.telepathy1 for hints defined
by this specification, or an appropriate vendor name for third-party
plugins).
This property may be set when the channel request is created, and can never change. Since it is immutable, it SHOULD be included in the dictionary of properties passed to AddRequest by the ChannelDispatcher.
The following standardised hints are defined:
- im.telepathy1.ChannelRequest.DelegateToPreferredHandler - b
- If present and True the client currently handling the channel
SHOULD pass the channel to the
PreferredHandler using
DelegateChannels.
If the channel is currently unhandled, clients SHOULD ignore this hint.
Rationale:
This hint allows the user to request a channel in their preferred client in a situation where there are two chat handlers (for example: requesting a channel in Empathy which is currently being handled by gnome-shell).The Handler should check each ChannelRequest of the Requests_Satisfied parameter of HandleChannels for the hint. The first request containing the hint SHOULD be used and all further hints SHOULD be ignored.Rationale:
It is assumed that Mission Control will correctly delegate an unhandled channel to the preferred Handler. This allows requesting clients to always include this hint in their channel request.Rationale:
This covers the very unlikely case where HandleChannels satisfies two separate requests which have different PreferredHandlers.