[Telepathy] Telepathy channel API design session

mikhail.zabaluev at nokia.com mikhail.zabaluev at nokia.com
Thu May 15 08:53:21 PDT 2008


Hello,

What follows are the minutes taken during an after the Telepathy channel API design
session in NRC Helsinki.

== Channel requestotron and improved NewChannel ==

A channel request carries a variant dictionary of requested properties
(interpreted as hints).
NewChannels carries a variant dictionary of channel's properties important
for dispatching, e.g. a call initiator, list of supported interfaces.
Same properties are available as channel's DBus properties.
A restriction on the initially reported properties is that they're immutable
throughout the channel's lifetime.

== Channel bundles ==

The way to group channels into one experience.
A unit of consideration for channel handlers/filters.
The bundle ID is an immutable channel property, thus a channel
cannot switch bundles. Adding a new channel to the bundle, or
closing a channel that's in the bundle, is possible.
If there's no handler for the whole bundle, the fallback behavior
is to handle each constituent channel separately.

== DBus namespace as a basis for registration of channel handlers ==

Similar to the approach with the connection managers.
Active clients install objects in the channel handler namespace.
Statically available .client files for activateable handlers,
similar to .manager files for connection managers.
If static property caching for a client is not practical,
activation for querying could still be used.

== Channel handlers vs channel filters ==

Three types of channel handlers:

1. Final handler for the channel/bundle. Usually it's the application
that provides the interaction UI for the channel/bundle
after it has been accepted.

2. Channel observer. The intended purpose is for cross-application watcher
agents such as logging, where the interested component would connect to a
channel to monitor the activities, but it won't be the final application
that provides the channel experience to the user.

3. Channel/bundle approver. This type handler would normally display a
notification to the user. After the user accepts or rejects the channel/bundle,
the control is passed back to MC, with a possible hint as to which of the
final handlers to launch.

A sequence for handling a new bundle in Mission Control:

 * The in-process filters are run against the bundle.
 * The matching observers are brought up and given the channel(s).
 * If suppress_handler was not specified:
   * The request DBus object is created and passed to all approvers matching
     the bundle parameters.
   * The first approver to call an action method on the request object wins,
     others are signalled to lose the request (reason: handled elsewhere).
   * If an approver has approved the bundle, a final handler is launched,
     using the optional hint from the approver.
   * An approver can also take the bundle, skipping all further processing.

Some corner cases:
 * If there are no registered approvers for the bundle, it goes directly to
   a final handler.
 * If there are no final handlers for the bundle/channels, the unhandled
   channels are closed (Variant: there is a configurable default handler
   that displays an error notification).

Issues:
Q1: Can observers modify channels, e.g. acknowledge text messages?
A1: In principle they shouldn't, but we don't have means to enforce that.

Q2: It's unclear which handler, the logger observer or the chat UI, should
acknowledge incoming messages.

Q3: A timeout for approvers to react should exist in MC for reliability.
This setting affects user experience.

== Mission Control channel request API ==

Unbreak the suppress_handler flag, so the requestor is not called back to
handle the same channel.

== Multitude of UIs for various types of text messages ==

Can be solved by creating a different channel for different types.
The guideline is that MC in general should stay out of watching
over channel contents.

-- 
  Mikhail Zabaluev,  Nokia Devices


More information about the Telepathy mailing list