Methods
| HandleChannel | (o: Account, o: Connection, o: Channel, a{sv}: Channel_Properties, a{oa{sv}}: Requests_Satisfied, x: User_Action_Time, a{sv}: Handler_Info) | → | nothing |
Properties
| HandlerChannelFilter | aa{sv} (Channel_Class_List) | Read only | ||
| BypassApproval | b | Read only | ||
| Capabilities | as (Handler_Capability_Token_List) | Read only | ||
| HandledChannels | ao | Read only |
Types
| Handler_Capability_Token | Simple Type | s |
Description
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 Call1 channels, or transferring the file in FileTransfer1 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.
Methods
HandleChannel (o: Account, o: Connection, o: Channel, a{sv}: Channel_Properties, a{oa{sv}}: Requests_Satisfied, x: User_Action_Time, a{sv}: Handler_Info) → nothing
Parameters
- Account — o
- Connection — o
- Channel — o
- Channel_Properties — a{sv} (Qualified_Property_Value_Map)
- Requests_Satisfied — a{oa{sv}} (Object_Immutable_Properties_Map)
- User_Action_Time — x (User_Action_Timestamp)
- Handler_Info — a{sv}
The Channel object. Its well-known bus name is the same as that of the Connection.
Properties of the channel, equivalent to the properties in Channel_Details.
The requests satisfied by this channel.
Rationale:
If the handler implements Requests, this tells it that this channel matches previous AddRequest calls that it may have received.
There can be more than one, if they were EnsureChannel requests.
Additional information about this channel. There is no key currently defined.
When more keys are defined for this dictionary, all will be optional; handlers MAY safely ignore any entry in this dictionary.
Called by the channel dispatcher when this client should handle this channel, or when this client should present a channel that it is already handling to the user (e.g. bring it into the foreground).
Rationale:
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 channel to another handler, or close the channel.
If closing the channel, it is RECOMMENDED that the channel dispatcher attempts to use Channel.Close, but resorts to calling Channel.Interface.Destroyable1.Destroy (if available) or ignoring the channel (if not) if the same handler repeatedly fails to handle a channel.
After HandleChannel returns successfully, the client process is considered to be responsible for the channel until it its unique name disappears from the bus.
Rationale:
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.
Properties
HandlerChannelFilter — aa{sv} (Channel_Class_List)
A specification of the channels that this channel handler can deal with.
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
If true, channels destined for this handler are automatically handled, without invoking approvers.
For service-activatable handlers, this property should be specified in the handler's .client file as follows:
[im.telepathy.v1.Client.Handler] BypassApproval=true
Capabilities — as (Handler_Capability_Token_List)
The set of additional capabilities supported by this handler. This describes things like support for streamed media codecs and NAT traversal mechanisms: see the Contact Capabilities interface for more details.
For handlers that have a .client file, the
channel dispatcher may discover this property from the
im.telepathy.v1.Client.Handler.Capabilities
group; for each capability, that group contains a key
whose name is the capability, with value true.
Keys with other values SHOULD NOT appear in this group.
For instance, the .client file for a streamed media
handler that supports ICE-UDP NAT traversal, Speex audio,
and Theora and H264 video might contain this group:
[im.telepathy.v1.Client.Handler.Capabilities] im.telepathy.v1.Channel.Type.Call1/audio=true im.telepathy.v1.Channel.Type.Call1/video=true im.telepathy.v1.Channel.Type.Call1/ice=true im.telepathy.v1.Channel.Type.Call1/audio/speex=true im.telepathy.v1.Channel.Type.Call1/video/theora=true im.telepathy.v1.Channel.Type.Call1/video/h264=true
Like the HandlerChannelFilter
property, this property cannot change while the Handler owns its
Client bus name. However, the .client file, if any,
can change (due to upgrades or installation of pluggable codecs),
and the capabilities really supported by the handler might not
exactly match what is cached in the .client file.
Rationale:
The client file is installed statically and is intended to list codecs etc. that the handler guarantees it can support (e.g. by having a hard dependency on them), whereas the running handler process might be able to find additional codecs.
HandledChannels — ao
A list of the channels that this process is currently handling.
There is no change notification.
Rationale:
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.
Rationale:
Otherwise, when a process released a temporary Client name, channels that it handled because of that Client name would no longer be state-recoverable.
Types
Handler_Capability_Token — s
Rationale:
So far, all client capabilities are defined by the Call1 interface.