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).
