Rationale

The design of Telepathy, and its approach to real-time communications comes from a very specific rationale:

  • 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 and open implementation of a given communications protocol is in a certain language, you are able to write your Connection Manager in that language and still have it available to all Telepathy clients.
  • Desktop independence: D-Bus has been adopted by both GNOME and KDE. Multiple user interfaces can be developed on top of the same Telepathy components.
  • 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 clients 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 session bus (e.g. making it possible to use an SELinux policy to prevent protocol code from accessing the disk).