Telepathy, Empathy and Mission Control 5 in GNOME 2.28
For many people, Telepathy is just an incredibly complex specification for implementing instant messaging clients. The truth is though, Telepathy is so much more. Telepathy allows programs on the desktop to use what we think of as Communications as a Service.
For many people, Telepathy is just an incredibly complex specification for implementing instant messaging clients. The truth is though, Telepathy is so much more. Telepathy allows programs on the desktop to use what we think of as Communications as a Service. Yes, it handles text and media communications and transfer files, but it can also be used for so much more, like transferring information between applications for collaboration over the internet. Communications as a Service means that communication is no longer the purview of one monolithic communications application and any application on the desktop can access the same set of shared communications accounts. This means communication is now possible all over the desktop. This has many exciting possibilities: opening text chat from Evolution, sending files to other users via Nautilus, collaboration with colleagues via Telepathy Tubes. We’ve only just begun to explore what’s possible here. This article talks about some of the features Telepathy offers in GNOME 2.28. For more information on Telepathy itself, see the Telepathy Overview article in this edition by Sumana Harihareswara.
Mission Control 5
One of the most exciting, yet under-hyped features in GNOME 2.28 is the transition to Mission Control version 5. Mission Control forms a core, and until recently absent, piece of the Telepathy infrastructure. It allows application developers to provide pluggable clients to handle all kinds of collaboration: VNC between contacts (available in GNOME 2.28), online gaming, collaborative document editing, event sharing (e.g. Zeitgeist). What exactly does Mission Control do you ask? Mission Control provides two important components of the Telepathy API: the Account Manager and the Channel Dispatcher. The Account Manager does what it says on the tin; it provides storage and retrieval for the user’s communication accounts (e.g. her XMPP account, MSN account, Google Talk account, Facebook chat account, etc.). It is also responsible for managing the presence (e.g. Available, Away, Busy, Out to Lunch) for each account (which may be individually different) and initiating the connection for each account via the respective Connection Managers (a Connection Manager is responsible for the connection and abstraction of a given protocol). The Channel Dispatcher is responsible for the handling of communications channels, for instance text, Voice-over-IP, file transfer or Telepathy Tubes. When a channel is created by a Connection Manager, the Channel Dispatcher is responsible for finding an application that can handle the channel (known as a Client). Empathy is an example of a Telepathy Client that can handle incoming text, voice/video and file transfer channels. As well as receiving incoming channels, the Channel Dispatcher can also be used to find a suitable client for a locally-initiated channel. For instance, Evolution might request a text channel to a certain user. The Channel Dispatcher can then dispatch that Channel to Empathy to carry out the text chat. There are three kinds of Telepathy Clients: Observers, Approvers and Handlers, although a single application might implement all three. Clients are either registered dynamically by the application while the application is running, or can be registered via a ”.client” file, so that the Channel Dispatcher can launch the Client when required. Each Client provides a list of channel types it is interested in (e.g. text, file transfer, streamed media, Tubes of a given type) via a D-Bus property, and optionally as part of the .client file (for clients that activate on demand). Observers are passive clients that simply observe what’s happening on a channel. An Observer might be used to implement logging of text chat, progress of file-transfer, list in-progress chats, or notify the user of incoming messages. Observers can be used to make some requests to a channel, for instance cancelling a file transfer. Any number of Observers are allowed to observe a channel, all running or activatable Observers are informed of incoming channels. Approvers are responsible for approving an incoming channel, either implicitly (as might be the case for text chat) or by asking the user if she wishes to receive the channel (e.g. for a VoIP call, file transfer or tube). The Approver can also recommend a Handler. All running or activatable Approvers are queried about an incoming channel, so ideally only one approver per channel type is available and should be provided by the desktop. Finally, there are the Handlers, the type of Telepathy Client that most developers will create. These are the applications that will handle the channel. Only one Handler is chosen for a given channel, which can be recommended by the Approver or chosen by the Channel Dispatcher. A typical handler might be the chat interface for a text channel, a VoIP UI or a Tube application. GNOME’s Empathy client provides Handlers for text, VoIP and file transfer channels.
Tubes and MC5
The most significant feature of this work for GNOME is enabling applications to utilise Telepathy Tubes. In Telepathy, we think of Tubes as contact-to-contact networking. Tubes enable one-to-one, one-to-many or many-to-many communication between contacts using either network sockets (stream tubes) or a private D-Bus bus (D-Bus tubes). This allows applications to support collaboration between users, with a minimal amount of effort on the part of both application developers and the end-user. Application developers can now focus on their application protocols, without having to worry about networking, firewall traversal or service discovery. End users no longer have to configure collaboration accounts, share IP addresses or forward ports on their firewalls. Here’s how it works. An application registers itself with the Channel Dispatcher indicating that it handles a certain type of tube. This Tube name is then advertised as a capability to users subscribed to your presence. If I want to play Sudoku against you, my Sudoku client requests a list of all my contacts who advertise the Sudoku Tube capability. The Tube is offered to the contact I select. Your Channel Dispatcher receives this channel and passes it to the Approver which displays a dialog asking if you would like to play a game of Sudoku against me. Assuming you approve the channel, the Channel Dispatcher then passes the channel to the recommended Handler (the game client) which can then accept the Tube. At this point our two applications are now connected via the Internet. [The Telepathy Connection Manager takes care of the precise method of connection, utilising whatever technologies are available with the given communications protocol.]
Empathy in GNOME 2.28 and beyond
Empathy in GNOME 2.28 has been reworked to take advantage of Mission Control 5, and now implements Handlers for text, file transfer and VoIP channels (it also provides an Observer which it uses to log text conversations). However, Empathy does not yet request outgoing channels via the Channel Dispatcher, which means that it’s not yet possible to replace a given Handler and have the channel launched from the Empathy roster. This will be fixed for Empathy 2.30, which will create a complete functional disassociation between each component of Empathy. This will allow Empathy to operate as a series of modular components and allow any individual component to be replaced (e.g. allowing for an improved multi-user chat interface). Empathy’s accounts configuration UI can become a configuration pane that talks directly with Mission Control’s Account Manager. Control of online presence, also handled via the Account Manager, can be integrated with the GNOME Shell or another desktop component. A full roadmap of Empathy related improvements is available at http://live.gnome.org/Empathy/Roadmap/Roadmap230. A telepathy-gtk library, complementing telepathy-glib, which provides widgets for Telepathy-related actions that applications are likely to need, for example a contact selector, is planned for the GNOME 2.29 development cycle. This cycle will also include further development to telepathy-glib, to make more common tasks easier (such as implementing a Tube Handler). Work is now taking place to look at how Telepathy might integrate into the GNOME Shell.
Metacontacts: The Missing Component
Telepathy provides no service supporting the idea of “metacontacts”, where individual contacts (and email accounts, etc.) provided by different protocols are unified into the concept of a single person. For example, you might have contacts in your roster for firstname.lastname@example.org, email@example.com and firstname.lastname@example.org, but so far there is no service responsible for storing that these are the same person. One solution that has been proposed that these relationships be stored in Tracker using the Nepomuk people ontology. Although desired in Empathy, this is somewhat out of scope for Telepathy itself, because it covers more than just information handled by Telepathy (e.g. email addresses, social networking accounts, etc.). It is, however, a problem of interest to Telepathy developers, and so we’re interested to hear from people who want to work to solve this problem.
Would You Like To Know More?
For developers who want to get started writing a Telepathy Client (e.g. using Telepathy Tubes in your application), Telepathy provides GLib’ish bindings via the library telepathy-glib. The latest version of these bindings provide classes to simplify dealing with the Account Manager. Although Telepathy is a D-Bus API, and thus can be used with any D-Bus library, this API is quite low-level. The bindings provide useful utility functions and classes that take the heavily lifting out of commonly repeated Telepathy operations. Note: there are two older libraries: libtelepathy and libmissioncontrol, but these libraries are very deprecated and should never ever be used. There is also a work-in-progress Telepathy book (http://people.collabora.co.uk/~danni/telepathy-book/), which includes numerous examples of implementing Telepathy applications. More information is also available at the Telepathy website, mailing listand IRC channel (freenode/#telepathy).
About The Author
Danielle Madeley is an Australian software developer working for Collabora Ltd. The first Linux distribution she used was RedHat 6.0. She enjoys taking photographs, playing the saxophone and eating vegan food. Her favourite colour is purple, but it used to be green.