From kde-pim Sat Aug 16 14:18:45 2008 From: Holger Berndt Date: Sat, 16 Aug 2008 14:18:45 +0000 To: kde-pim Subject: Re: [Kde-pim] Akonadi being a desktop-indepent standard Message-Id: <20080816161845.5c637479 () wodan> X-MARC-Message: https://marc.info/?l=kde-pim&m=121889637832116 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): 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/