[Evolution-hackers] Interface Spec for PIM component interoperability

[Holger Berndt <berndth gmx de>]

Hello Evolution hackers,

I just subscribed to the list, and browsing the archives this message
may or may not have an overlap with the recent thread about EDS D-Bus
interface in "Future of eds bindings".

I am a supporter of the desktop independant, GTK+ based MUA Claws Mail.
Its (few) developers are pretty evenly split between between being KDE,
GNOME, and XFCE users.

I've thought many times that it would be great to have a
(maybe freedesktop.org) standard for PIM component access and
interaction. Ideally, this would allow for all PIM components
implementing this spec to be interchangable without loosing
integration, so the user could choose calendar, addressbook, mailer etc
independantly, and still have a nicely integrated PIM suite. This could
be achieved by defining a "common language" for popular PIM tasks
involving multiple components (by "PIM component", I mean MUA,
calendar, addressbook, notes application etc).

Let me give a few examples of such tasks:
What a MUA could request:
- dear addressbook, whoever you might be, please add the following 
contact: John Doe <john doe tld org>
- dear addressbook, please give me a list of all contacts
- dear addressbook, please open up contact xy for editing. Or just show 
me your main window.
- dear calendar, whoever you might be, I just received a meeting 
invitation via email. Please insert that event into my calendar

Basically, it would be necessary to define a set of interfaces
(possibly D-Bus services) along the lines of
 org.freedesktop.pim.addressbook.storage
 org.freedesktop.pim.addressbook.ui
 org.freedesktop.pim.calendar.storage
 org.freedesktop.pim.calendar.ui
 org.freedesktop.pim.mua.storage
 org.freedesktop.pim.mua.ui
etc, where in the case of GNOME Evolution could provide the *.ui
interfaces and EDS could provide the *.storage interfaces.

Of course signal/slot connections would also be possible (e.g. the
MUA signalling: "Hey, whoever might care: A new mail arrived").

The user would just have to define which applications
should provide which service (possibly via D-Bus .service files), and
have an integrated PIM suite with his preferences of the individual
components.

This would also ease accessing PIM data for 3rd party applications,
and/or common tasks like synchronization. For example, not every
application would have to write its own OpenSync plugin, but a single
plugin implementing the spec would be enough for all PIM solutions.

Of course, such an interface only makes sense if the major players are
interested in that kind of interoperability. So I've also brought that
topic up on the KDE-PIM mailing list at
http://lists.kde.org/?t=121888172500007&r=1&w=2
Discussion is on-going, but they seem to be interested in general.
What's the Evolution hackers' point of view?

Regards,
Holger