Version 0.1
| Revision History | ||
|---|---|---|
| Revision 0.1 | 30 August 2008 | hb |
| Inital draft. | ||
Abstract
Abstract.
Table of Contents
This is a draft specification for interaction between modules of a Personal Information Management (PIM) toolchain. Examples for such modules are a mail user agent (MUA), an addressbook, or a calendar application. As these modules have to interact during many common PIM tasks, complete PIM suites need to be used in order to have an integrated solution. Examples for this kind of interactions could be
The MUA requests an address to be added to the addressbook
A MUA receives a meeting invitation, and requests the calendar to add that event
The user creates a new meeting in the calendar, and asks the MUA to send out invitations for all participants of this event
The user receives an email with a new address of a contact, and asks the addressbook to open that contact for editing
Desktop integration features and common tasks like synchronisation need to be implemented on a per-application and per-desktop basis. This is not only inefficient, but also makes the desktop integration task for desktop-independant third-party applications hard.
Having a common language for PIM module interactions would not only allow third party applications to integrate into every desktop following this specification, but also allow for the end user to freely choose each PIM module individually without loosing integration. A synchronisation application based on this specification would be able to provide synchronisation for all applications following this specification without extra effort for individual application developers.
This specification defines a set of D-Bus services and interfaces describing functionality that PIM components can choose to offer. These services occur in pairs: Each module has one service for user interface requests and one service for accessing the corresponding data storage. This is done so that applications can choose to offer only data storage (e.g. Evolution Data Server, Akonadi), only user interface (e.g. Evolution, KDE-PIM), or both kinds of services (e.g. Claws Mail, Thunderbird).
Each PIM module should register to the services that they want to provide via D-Bus .service files. The applications will then get launched automatically whenever that service is requested and the application is not running.
Up to date, D-Bus service files are not yet dynamic enough to hold this kind of configuration, see (TODO: create bug and insert link here)