Mission Control, or MC, is a Telepathy component providing a way for "end-user" applications to abstract some of the details of connection managers, to provide a simple way to manipulate a bunch of connection managers at once, and to remove the need to have in each program the account definitions and credentials.
Misson Control implements some well-defined API's much like each connection manager respond to a set of well-defined telepathy API's. The set of API's implemented by MCs will be split in several interfaces to ease progressive and adaptative implementation of each facet.
There are different types of files that the MC will use, and that are installed by the various connection managers package or third-party application needing to be hooked-in. See FileFormats for details. MC is able to handle all those file formats as expected.
MC is able to read and write the user's account information. This include various parameters such as, the connection-manager profile and any other useful information used for each defined connection.
Currently it uses gconf backend for storing account information (account parameters, like the passwords, full name, avatar etc.), but in future, it is expected to use flexible and plugable strorage (example: gnome-keyring).
When creating a user account, the UI (outside mission-control) should present to the user a list of all available connection-manager profiles, and remove or differentiate duplicate vanilla profiles (see FileFormats). This is a policy left to the application implementor and requires no API.
MC would in future be also able to cache the dbus service names for each managed connection to be able to recover gracefully in case of crash (hooking up into existing MC-created connection after the recovery: using ListNames on the bus and matching any existing dbus service against the cached name).
The user accounts are not expected to be updated 'live' when some parameters are changed. There is a 'changed' signal indicating that the account needs a reconnection to use the new settings, and the account configuration UI (outside MC), or any other component, should handle that signal in a meaningful way for the user. User accounts are identified with a unique fixed string (internally formed by concatenating the connection manager name, the protocol name, and a unique number).
Every defined user account has a toggle to enable/disable it. When a user account is disabled it will never be used, it will never be returned in the MC accounts API calls and would never appear in any external UIs (except the account configuration UI). When a user account is disabled it is automatically disconnected and the user account goes offline. When a user account is enabled it is automatically set to the existing presence state (connecting if needed, etc).
Every defined account has a user-defined friendly name (that the application using MC can fill-in automaticallly if omitted). This name will be used for differentiation his accounts in a more simpller display name (along with the username of each of his accounts). That way it is possible to differentiate two jabber accounts:
There are APIs in MC to allow listing existing user accounts and retreiving enough information to be able to display to the user what is needed. For example, an Addressbook application can decide to associate this information with the addressbook contacts. Some other application may decide to use it in different way and is left to the application. The API for this task is defined under the User accounts interface.
MC try to keep syncable settings across all connections in a consistent state with respect to the servers. Syncable settings are defined as:
When changing one of the syncable settings, the MC does whatever is necessary to bring all user accounts in the desired state (ie. connecting disconnected accounts, setting the desired presence, or disconnecting in case of going to offline presence, upload new avatar to all active connections, ..).
In case of an error in one of the connections, the MC retrys a number of times and finally if the error persist give up with that particular connection and signal the problem for further processing by UI applications.
MC allows applications to request for new channels. Applications will want telepathy channels of different types to be created for certain persons. For example, the chat UI application can request a chat channel and so on. Note: If an application wants to create a channel and handle it itself, it shouldn't go through the MC since only the application is responsible for that channel. All channel requests going through the MC will be dispatched with the .chandler mechanism (see FileFormats)
There will be two ways of requesting channels to be created and handled by the MC.
The API details for this task will be defined under the Channels interface.
When a NewChannel event is fired in one of the managed connections (for example a chat message is received), the MC performs a lookup in the .chandler files and activate every matching channel handlers, which usually are the UI applications capable of processing that new channel (For example, chat application for chat channels. Etc.).
Mission control can be extended in some ways. An external (environment specific) implementation of mission-control can override or introduce more functionalities to it. Policy for such events is not defined, and is up to the implementor to match the global look & feel of the platform he is developping the MC for.
There are two ways to extend mission-control:
Filter plugins are just external components that can be installed by outside applications to affect how the channel handlings are performed with respect to the environment or desktop it is on. Mission control does not provide any default plugins for this. So by default, all channel handler applications are launched straight way when new channels arrive. This feature exposes no dbus API.
Mission Control provides a basic default implementation of the server daemon, which can be disabled if an extended implementation of the server is used.