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