Why does Telepathy take a modular approach to real time communications?

  • 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