This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

(as a draft)

Channel handlers are the eventual handler for a channel or a channel bundle; a typical channel handler is a user interface process handling channels of a particular type.

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.

A 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.DRAFT.ObserverChannelFilter property. 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.

If 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)

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, or if the handler loses its bus name before all the channels have closed, the handler is assumed to have failed or crashed, and the channel dispatcher MUST recover in an implementation-specific way.

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.

The Account with which the channels are associated. The well-known bus name to use is that of the AccountManager. The Connection with which the channels are associated. The well-known bus name to use can be derived from this object path by removing the leading '/' and replacing all subsequent '/' by '.'. The channels and their immutable properties. Their well-known bus name is the same as that of the Connection. The requests satisfied by these channels. There can be more than one, if they were EnsureChannel requests. The time at which user action occurred, or 0 if this channel is to be handled for some reason not involving user action. Handlers SHOULD use this for focus-stealing prevention, if applicable.

Called by the ChannelDispatcher to indicate that channels have been requested, and that if the request is successful, they will be handled by this Handler.

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.

(FIXME: how do we know the returned channels will be handled by this handler? Do we just assume that they'll match the HandlerChannelFilter iff the request does?)

The ChannelRequest object, which MUST have been returned by CreateChannel or EnsureChannel before this method is called. See those methods for the rationale of this ordering.

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 and UserActionTime MUST be included.

Called by the ChannelDispatcher to indicate that a request previously passed to AddRequest has failed and should be disregarded.

The request that failed.

The name of the D-Bus error with which the request failed.

If this is org.freedesktop.Telepathy.Errors.NotYours, this indicates that the request succeeded, but all the resulting channels were given to some other handler.

Any message supplied with the D-Bus error.

A list of the channels that this Handler 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.