Telepathy: Difference between revisions
No edit summary |
|||
Line 35: | Line 35: | ||
OLPC uses the following CMs: |
OLPC uses the following CMs: |
||
* [[Telepathy |
* [[Telepathy Gabble|Gabble]]: for XMPP via a Jabber Server |
||
* [[Telepathy |
* [[Telepathy Salut|Salut]]: for link local XMPP |
||
See [[Activity sharing]] for an overview of activity collaboration, and [[Presence Service]] to see how the Sugar stack interfaces with these Telepathy CMs. |
See [[Activity sharing]] for an overview of activity collaboration, and [[Presence Service]] to see how the Sugar stack interfaces with these Telepathy CMs. |
Revision as of 18:20, 18 June 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
Presentation
See Rob McQueen's recent presentation on Telepathy at linux.conf.au: OGG SPX
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 Activity sharing 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...)
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.
Proposed Standards
These documents were generated from the XML files included in telepathy-gabble/docs and telepathy-salut/docs:
- XEP-proto-olpc1.0: OLPC-specific properties, version 1.0
- XEP-proto-tubes: Tubes over XMPP
- XEP-proto-muc-bytestream: MUC Bytestreams
- XEP-proto-clique: Clique - link-local chat rooms
More Telepathy Documentation
The Telepathy wiki has documentation. In particular, see the following documents: