11.0 (Conspect) Application bus
POSIX API (signals, messages, shared memory)
Disadvantages:
- No message data structure is provided (just number or raw memory)
- can not verify
- No multicast (one-to-many)
No organized namespace (remember /dev/shm names clash?)
Way too redundant, being solely implemented in kernel-space
History:
- Every application suit is developing it's own high-level IPC
- too overdesigned
D-Bus
Concepts:
- API
- Cross-platform implementation (e. g. on Linux is probably on sockets, but who cares)
- Has dedicated server Any client:
- Connects to the bus
- Can browse all service published
- Can call for some service
- Can publish own service and answer for call
- Can subscribe for some broadcast messages (signals)
- Can publish a signal emitter
- Has joint namespace with simple naming conventions to avoid clash
- Standardized by freedesktop.org
- All published objects/methods are introspectable
Linux: there are at lease two d-buses:
- system — to control system services (by admin)
- session (user) — to control user services (by user)
Architecture
Connection ID and published well-known name (looks like backward worded domain name). Analog of domain name in URL.
- 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
- Interfaces. The suite of announced methods. Analog of Ada of Java interfaces.
- Methods/Signals/Properties.