Client.I.Requests — Telepathy D-Bus Interface Specification

# Interface Client.Interface.Requests

Interface Index (Compact) | Summary | Description | Methods

### Methods

AddRequest | (o: Request, a{sv}: Properties) | → | nothing |
RemoveRequest | (o: Request, s: Error, s: Message) | → | nothing |

Added in 0.17.26. (as a stable interface)
Objects implementing this interface must also implement:

- org.freedesktop.Telepathy.Client
- org.freedesktop.Telepathy.Client.Handler

### Description

This interface can be implemented by a Handler to be notified about requests for channels that it is likely to be asked to handle.

# Methods

(Permalink)

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

### Parameters

- Request — o
The ChannelRequest object, which MUST have been returned by CreateChannel or EnsureChannel before this method is called.

##### Rationale:

See those methods for the rationale of this ordering.
- Properties — a{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, UserActionTime and Account MUST be included, and Hints MUST be included if implemented.

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.

##### Rationale:

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.

##### Rationale:

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.

##### Rationale:

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.

##### Rationale:

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.

##### Rationale:

Calls to this method are merely a notification.

(Permalink)

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

### Parameters

- Request — o
The request that failed.
- 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
Any message supplied with the D-Bus error.

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.

##### Rationale:

Calls to this method are merely a notification.