Interface ChannelRequest

Interface Index (Compact) | Summary | Description | Methods | Signals | Properties

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
Added in 0.17.26. (as a stable interface)

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

(Permalink)

Proceed () → nothing

Proceed with the channel request.

Rationale:

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

  • Not Available
  • This method has already been called, so it is no longer available. Stop calling it.
(Permalink)

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

(Permalink)

Failed (s: Error, s: Message)

Parameters

  • 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
  • If the first argument of the D-Bus error message was a string, that string. Otherwise, an empty string.

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

(Permalink)

Succeeded (o: Connection, a{sv}: Connection_Properties, o: Channel, a{sv}: Channel_Properties)

Added in 0.21.5.

Parameters

  • Connection — o
  • The Connection owning the channel.

  • Connection_Properties — a{sv} (Qualified_Property_Value_Map)
  • A subset of the Connection's properties, currently unused. This parameter may be used in future.

  • Channel — o
  • The channel which has been created.

  • Channel_Properties — a{sv} (Qualified_Property_Value_Map)
  • 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

Accessed using the org.freedesktop.DBus.Properties interface.
(Permalink)

Account — o

Read only
The Account on which this request was made. This property cannot change.
(Permalink)

UserActionTime — x (User_Action_Timestamp)

Read only

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.

(Permalink)

PreferredHandler — s (DBus_Well_Known_Name)

Read only

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.

(Permalink)

Requests — aa{sv} (Qualified_Property_Value_Map_List)

Read only

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.

(Permalink)

Interfaces — as (DBus_Interface_List)

Read only
A list of the extra interfaces provided by this channel request. This property cannot change.
(Permalink)

Hints — a{sv}

Read only
Added in 0.21.5.

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:
This property might be used to pass a contact ID for a telephone number shared between two contacts from the address book to the call UI, so that if you try to call “Mum”, the call UI knows this rather than having to guess or show “Calling Mum or Dad”. The format of these contact IDs would be platform-specific, so we leave the definition of the dictionary entry up to the platform in question. But third-party channel requesters might not include the contact ID, so the call UI has to be able to deal with it not being there.

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.
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).
If the channel is currently unhandled, clients SHOULD ignore this hint.
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.
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:
This covers the very unlikely case where HandleChannels satisfies two separate requests which have different PreferredHandlers.