11.0 (Conspect) Application bus

POSIX API (signals, messages, shared memory)

Disadvantages:

1. No message data structure is provided (just number or raw memory)
2. can not verify
3. No multicast (one-to-many)

4. No organized namespace (remember /dev/shm names clash?)

5. Way too redundant, being solely implemented in kernel-space

History:

1. Every application suit is developing it's own high-level IPC
2. too overdesigned

D-Bus

Concepts:

1. API
2. Cross-platform implementation (e. g. on Linux is probably on sockets, but who cares)
3. Has dedicated server Any client:
4. Connects to the bus
5. Can browse all service published
6. Can call for some service
7. Can publish own service and answer for call
8. Can subscribe for some broadcast messages (signals)
9. Can publish a signal emitter
10. Has joint namespace with simple naming conventions to avoid clash
11. Standardized by freedesktop.org
12. All published objects/methods are introspectable

Linux: there are at lease two d-buses:

1. system — to control system services (by admin)
2. session (user) — to control user services (by user)

Architecture

1. Connection ID and published well-known name (looks like backward worded domain name). Analog of domain name in URL.

2. Objects. Analog of filename path in URL.

   

   • Of program announce one object, it's path will probably look like well-known name with "." replaced with "/" with leading "/"

   • One program can announce more than one object

3. Interfaces. The suite of announced methods. Analog of Ada of Java interfaces.

   

4. Methods/Signals/Properties.