[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi being a desktop-indepent standard
From:       Holger Berndt <berndth () gmx ! de>
Date:       2008-08-16 14:18:45
Message-ID: 20080816161845.5c637479 () wodan
[Download RAW message or body]

Hi Kevin,

On Sa, 16.08.2008 15:08, Kevin Krammer wrote:

>> I've thought many times that it would be great to have a
>> freedesktop.org standard for PIM component access and interaction.
>> Ideally, this would allow for all PIM components implementing this spec
>> to be interchangable with out loosing integration, so the user could
>> choose calendar, addressbook, mailer etc independantly, and still have
>> a fully integrated PIM suite.
>
>We definitely agree on this. There is enought room for any kind of 
>specialization or customization for different user target groups on the 
>application level, without need to do all the data I/O and manipulation 
>multiple times.

Re-reading project pages of Akonadi, I understand that the project is
mostly about providing a central storage and access management for PIM
data. 

I am not sure many 3rd party applications would want to rely on that. I
am pretty certain, for example, that the Claws Mail dev team would not
aggree on outsourcing actual mail message storage.

>> This would also ease common tasks like synchronization. For example,
>> not every PIM suite would have to write its own OpenSync plugin, but a
>> single plugin implementing the spec would be enough for all PIM
>> solutions.
>
>As far as I understand the OpenSync framework already allows this to some 
>extent, i.e. using the same device plugin independent from whether it sync to 
>a KDE based local store or that of another PIM project.

Well, in OpenSync, you have plugins for hardware devices (Nokia,
Motorola, SyncML-based stuff etc) and applications (KDE PIM, Evolution,
I was working on one for Claws Mail etc.) Basically, what the
application plugin implements is listing/adding/modifying/deleting
entries in addressbooks or calendars. The Evolution plugin talks to the
Evolution Data Server for that, the KDE PIM does it the KDE way, the
Mozilla plugin talks to Thunderbird etc.

>Yes, Akonadi is intended and has been designed to be desktop independent.
>The central core is basically specified by a data transport protocol and D-Bus 
>interfaces for out-of-band communication (notifications, etc).

[Akonadi's client server architectur description cut]

>> Note that many useful tasks would probably not even require a daemon,
>> but could be implemented client-side based on a D-Bus spec.
>> Synchronization would be an example, that would mostly just require a
>> standardized set of get/add/delete/modify interface methods for
>> addressbook, calendar, and notes.
>
>I am not so sure about that.
>The daemon/service based approach avoids nasty things like file 
>locking/concurrent access, identifier consistency, relyable change 
>notifications and so on

I see. It does seem to me, after all, that we are talking about
different things here. While Akonadi wants to concentrate data storage
and access at a central point, I was more talking about a "common
language" for otherwise independant PIM modules.

Since the goals are similar, though, maybe not all hope is lost. Let me
explain what I envision, and where Akonadi's place could be:

There could be a spec for PIM module preferences, maybe D-Bus based, in
the freedesktop.org namespace, according to which each user can define
his own choice of programs. Technically, this could be done by D-Bus
service files.

Each program supporting this spec would have to implement a
corresponding interface. Though I don't know Akonadi well, that
interface could probably be based on what Akonadi supports already
anyways. In the easiest case, the API for an addressbook could contain
something like that (D-Bus xml excerpt):

  <interface name="org.claws_mail.addressbook">
    <method name="GetContacts">
      <arg type="as" name="ret" direction="out"/>
    </method>
    <method name="AddContact">
      <arg type="s" name="contact" direction="in"/>
      <arg type="s" name="ret" direction="out"/>
    </method>
    <method name="DeleteContact">
      <arg type="s" name="uid" direction="in"/>
    </method>
    <method name="ModifyContact">
      <arg type="s" name="uid" direction="in"/>
      <arg type="s" name="contact" direction="in"/>
      <arg type="s" name="ret" direction="out"/>
    </method>
  </interface>

Data transfer should be in a well known, well defined format, such as
strings of vcards in the case of an addressbook.

Now, all PIM modules relying on Akonadi would configure the D-Bus
services for addressbook, calendar, mail, etc. to point to Akonadi.
Still, 3rd party applications could integrate seamlessly.

To come back to the synchronization example: Instead of an Evolution
plugin, a KDE PIM plugin, a Claws Mail plugin, a Thunderbird plugin
etc, only a D-Bus plugin would be necessary for all PIM components that
implement this spec.

Holger
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]