blob: 4517dd9ed5144d42f77c7008e25628fe19cb8f1a (
plain)
1
2
3
4
5
6
7
8
9
10
11
|
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
|
