Telepathy: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 31: | Line 31: | ||
OLPC uses the following CMs: |
OLPC uses the following CMs: |
||
* [[ |
* [[Telepathy-gabble|Gabble]]: for XMPP via a Jabber Server |
||
* [[ |
* [[Telepathy-salut|Salut]]: for link local XMPP |
||
See [[Shared Sugar Activities]] for an overview of activity collaboration, and [[Presence Service]] to see how the Sugar stack interfaces with these Telepathy CMs. |
See [[Shared Sugar Activities]] for an overview of activity collaboration, and [[Presence Service]] to see how the Sugar stack interfaces with these Telepathy CMs. |
Revision as of 11:54, 4 February 2008
Overview
Telepathy is a framework for real-time conversations, including instant messaging, IRC, voice calls and video calls. It provides a modular approach to implementing these types of communications, so that applications do not have to reimplement common functionality.
Telepathy uses the D-Bus IPC system between components, allowing development of new components in any language, to conform to the Telepathy D-Bus specification. This means that Telepathy components can be added to existing applications which can talk D-Bus, without a hard dependency.
Telepathy is supported by Collabora Ltd
Rationale
Benefits of Telepathy's modular approach:
- Robustness: one component can crash without crashing others
- Ease of development: components can be replaced within a running system; tools like dbus-inspector can trace interactions between components
- Language independence: components can be written in any language that has a D-Bus binding; if the best free implementation of the Oscar (AOL) protocol is in Java, you can write your Oscar connection manager in Java to take advantage of that
- Desktop independence: D-Bus has been adopted as an IPC mechanism by both GNOME and KDE
- License independence: components can be under different licenses that would be incompatible if all components were running in one process
- Code reuse: Telepathy allows clients to ignore protocol details as much as possible, easing transitions between different communications systems
- Connection reuse: multiple Telepathy components can use the same connection simultaneously
- Security: components can run with very limited privileges; a typical connection manager only needs access to the network and to the D-Bus bus, making it possible for an SELinux policy to prevent protocol code from e.g. accessing the disk
(from http://telepathy.freedesktop.org/wiki/)
Connection Managers
Telepathy Connection Managers (CMs) provide the back ends for protocols. Since these are modular, a Telepathy-enabled application can use whichever CMs are available, providing they support the appropriate interfaces.
Used by OLPC
OLPC uses the following CMs:
See Shared Sugar Activities for an overview of activity collaboration, and Presence Service to see how the Sugar stack interfaces with these Telepathy CMs.
See Activity Sharing for some historical discussion on the rationale of using Telepathy for OLPC.
Other CMs
In addition, there are CMs implemented for the following protocols:
- Idle: IRC
- Telepathy-SofiaSIP: SIP
- Butterfly: MSN
- Haze: uses libpurple to provide all the protocols that Pidgin supports (AIM, ICQ, Yahoo, MSN...)
More Telepathy Documentation
The Telepathy wiki has documentation. In particular, see the following documents:
Telepathy Spec
At the core of Telepathy is the DBus interface specification which describes how Telepathy components communicate with each other. See Telepathy D-Bus Interface Specification for the current version.