Lynyrd Skynyrd rocks, but you already knew that.
Will Stephenson rocks as well and you quite likely also already knew that.

Free Bird is one the reasons why Lynyrd Skynyrd rocks and one of the reasons why Will Stephenson rocks is that he took over the gargantuan task of moving the Akonadi server to is KDE independent location in kdesupport.

"Gargantuan". You know, I've always liked that word "gargantuan", I so rarely have the opportunity to use it in a sentence. -- Elle Driver (Daryl Hannah) in "Kill Bill 2".

Usually moving code in a SVN repository isn't that hard, but although we were very thorough about not getting KDE dependencies into Akonadi server, a lot of its build system related things were.
So making Akonadi server build again in its new location and making Akonadi dependent code in kdepimlibs and kdepim build again was truely a gargantuan task (twice in one blog entry, not bad).

Additonally, several other developers, including Mr. Buildsystem Alex Neundorf, have done some cleanups and thus further improve Akonadi's cross-desktop characteristics.

We still need to clean up some KDE name references, such as D-Bus names, etc. and setup project infrastructure on freedesktop.org, but I am quite confident that this won't take a lot of time. Until then, meet us Akonadi developers on IRC channel #akonadi, freenode network.

speaking of logos, and while I'm in 1:N communication mode and have your kind attention, large and lovely N that you are: we're in need of a vector version of the current Kontact logo, for purposes of blowing it up indecently in size for use in a poster or two (for Linuxtag). If you, dear k \in N, happen to be in possession of such, or happen to know j \not\in N, but the creator of said artwork, or happen to be j \in N, said creator, yourself, please get in contact with me at your earliest convenience for the overall furtherance of the ascent of the K (assuming |K| > |N| without loss of generality).

As Tom announced a few days ago, the Akonadi team is looking for a logo and an icon for the little system tray application. So far we have three submissions, but us kdepim hackers at KDAB thought we'd give folks an extra incentive by donating a Canon Powershot digital camera, new and unused, to be given to the creator of the work we will chose in the end. This fine and only slightly out-of-date (as digital cameras are doomed to be the moment one takes them off the shelf) piece of gear can be yours, yes, yours, if you add your submission to the techbase page and we end up selecting it in a process that will very likely be utterly subjective, unfair, unprofessional and morally objectionable. So there. Keep those submissions coming!

Other mentors have already blogged about their GSoC projects, so I am going to do the same for Akonadi.

Basically Akonadi got three slots from KDE and one from OpenChange.

Lets start with the one from OpenChange: Brad Hards will be mentoring student Alan Alvarez, who's goal is to implement an Akonadi resource based on the OpenChange MAPI library.
If he succeeds it allow Akonadi and thus all Akonadi-enabled clients, to access mails, contacts and calendar items stored on a Microsoft Exchange server, using the same access mechanism as Micrsoft Outlook, i.e. not requiring that the Exchange administrator enables any additional transport such as OWA

The first of the Akonadi GSoC projects hosted by KDE is a RSS framework for Akonadi, where student Dmitry Ivanov is mentored by Akregator maintainer Frank Osterfeld.
The goal of this project is to have a central service for aggregating news feeds, so applications like Akregator or KNewsTicker can access the same data without requiring them to implement article transfer and storage multiple times.

The second project is by student Igor Trindade Oliveira and he will be mentored by me.
Igor's plan is to implement a test framework for Akonadi, so that resource developers like Alan or Dmitry, application developers like Tom Albers and the Akonadi team members can more easily run tests on their creations.
Currently running reproducible test scenarios requires to manually setup a clean test environment, manually start the required set of processes, manually manipulating files or remote storage, manually... (I guess you get the picture).

One of the probably most interesting parts from the point of view of a larger audience will be the possibilty to script Akonadi data processing through a Kross bridge, which might also be useful for developers and power users of Akonadi PIM applications.

The third Akonadi related project is officially about modernizing KPilot where student Bertjan Broeksema will be working under guidance of mentor Jason Kasper. I am blogging about this because syncing of PIM data will using Akonadi on the sync's desktop side.

Like all other KDE subprojects we got a lot more good proposals than we had GSoC slots for, for example three very good applications for implementing an Akonadi resource which uses Google's data API to transfer data from/to Google's web-based PIM apps.

Since the Akonadi related applications for GSoC so far have been mostly about interfacing with external PIM data storage systems, e.g. Google's web based apps, I'd like to a bit of advertising for two other things we'd really like to have somebody working on.

The first one is the test framework idea I added to our list (second item). True, testing and stuff related to testing are usually quite boring, but it is nevertheless necessary and would be a great help for any one working on or with Akonadi.

To not leave the fun aspect out of the equation, one idea how to implement it would be to create a pair of scriptable Akonadi Agent and Resource, e.g. through a Kross plugin, effectively making it possible to work on Akonadi managed PIM data from any language Kross has support for.

The second project I'd like to get more widespread publicity is basically a matter of extending the target audience by getting support for developers on other desktop environments or tool stacks.
The idea is to implement a GLib based Akonadi client library, i.e. an GLib equivalent to KDE's Akonadi client library libakonadi-kde.

Unless other KDE related GSoC projects this would not require C++ and Qt skills, but rather C and GLib skill.
Till Adam would be available as a mentor, though we would really also have a GLib expert as an additional co-mentor or advisor.

Any student interested in either project can contact us on the kde-pim mailinglist or on IRC channel #akonadi on the freenode network.

Additionally to the migration path for PIM applications there are similar options for the actual data access facilities, i.e. the addressbook and calendar plugins traditionally used to access PIM data in local files, groupware servers and so on.

In the Akonadi universe this task is handled by programs we developers refer to as Akonadi resources.
Based on a suggestion by Till Adam, I created two such resources based on our traditional data access plugins, one for addressbook plugins and one for calendar plugins.
This should allow us to port the functionality currently implemented by our traditional plugins one by one and it also decouples the porting efforts of applications and storage facilities.

The following image shows three setups: one for each "end" of the transition and one intermediate step based on the example of an addressbook storage on a Kolab server

(click here for full size)

• Traditional setup
  In the traditional setup based on the KResource framework, each application would use plugins to access the storage device directly.
  When compared to the other two setups is looks a lot simpler and it in some way it is. However this approach is also more primitive, a lot of work is done multiple times, i.e. each application has its own connections to the Kolab server and each application is transferring all the data.

• Migration setup
  The main advantage of this setup is to fold the multiple instances of data access into one.
  For simplicity of the diagram I assumed that the accessing KAddressBook has already been ported to use Akonadi natively, but of course it would also work in its traditional form using the "akonadi" plugin described in part 1.

• Future setup
  If your first impression of this setup is that it is less flexible than the one before because it does not use plugins any longer, be assured it is not. Different types of storage devices are now handled by their special resource handler program, where each of them can be specifically tailored to the capabilties of the storage device it is working with. Quite like plugins but with added bonuses like not taking down an end-user application in case of crash. Pretty much comparable to how KDE has been using KIO slaves for document centric data access.

  If your second impression is that this setup introduced overhead because its resources are processes of their own, be assured it does not.
  Both the traditional and the migration setup require one plugin per type of PIM data and storage device, potentially resulting in more than one connection per application to a remote storage, whereas the new kind of resources can handle all their storage device supported types simultaniously.

Btw, a similar approach could also be used to create a migration path for applications currently using libedata-book and libedata-cal, i.e. applications currently using the Evolution Data Server as their storage service. Ideally using a GLib based Akonadi library similar to our libakonadi, but since these applications already expect to communicate with a local server, one could also implement an Akonadi agent using libakonadi that just "look" like EDS protocol-wise (probably using the D-Bus based EDS implementation Ross Burton created for the Embedded EDS)

As promised I am going to try to present the work I have been doing over the last couple of weeks in a less developer centric way.

Bascially the idea is to have an intermediate step in moving from the traditional facilities for addressbook and calendar to the future ones based on Akonadi.
This intermediate step should allow developers to migrate both applications and data acesss methods (e.g. groupware server access) one by one, so that new applications can already make use of all the possibilities of Akonadi while at the same time allow existing applications to adapt at their own pace.

Lets discuss the different approaches based on an common use case:

assume you are running KMail and at some time during the day you'd like to change some contact information in your addressbook so you start KAddressBook as well, modify the contact and save the modification.
Of course you also expect KMail to also know about this modification, e.g. if you changed somebody's email address, you want to have this new address when getting autocompletion suggestions.

The following image shows the three setups side by side:

(click here for full size)

• Traditional setup

The traditional setup is based on plugins we developers refer to as KResource framework.
For KDE's addressbook the default plugin is called "file" which means the contact data is stored in a file called "std.vcf" on your local harddisk.
The applications, in this case KMail and KAddressBook, actually don't have to care about which plugin is used, from their point of view they all look the same.

In the use case described above, both applications read the file and parse the contact data stored in it into objects we developer refer to as "Addressees".
At the time in the use case where KAddressBook saves the modifications, it overwrites the current file with the contact data it currently has stored in its addressee objects, i.e. also "replacing" the unchanged ones.

The "file" plugin inside KMail actually watches this file for changes, so it detects that someone has altered it and basically repeats its loading procedure, i.e. loading the file and parsing the contact data again.

• Migration setup

The migration setup is quite similar on the upper part of the diagram, i.e. KMail and KAddressBook still use plugins to access the data from a shared source.
However, this shared source is now a process by itself, the Akonadi server. The actual data reading and writing has been delegated to a specialized handler called the VCard resource.

In the use case described above, only this very resource handler has access to the storage file. It loads and parses the contact data similar to how the "file" plugin of the tradition setup did, so not a big difference yet.
Without going further into boring developer details the data is then transferred to the Akonadi server.

As I wrote above the two applications basically don't care which plugin they told to use, so from their point of view there is no difference in used a plugin called "akonadi" and they have no idea that this plugin is getting the data from the Akonadi server.

The main difference to the traditional setup is they way how the modification is handled.
When KAddressBook tells the "akonadi" plugin to save the addressbook it uses an Akonadi facility called ItemSync to only upload the modified addressees to Akonadi. The Akonadi server in turn notifies all interested parties, in this case KMail, KAddressBook and the VCard resource about the change.
In contrast to the traditional setup, the "akonadi" plugin inside KMail now only needs to fetch the modified addressee and only needs to get it from the Akonadi server and not from a storage device like a file.

To summarise the traditional applications can, without any code modifcations, already reap some of the advantages of Akonadi, e.g. fast distribution of local changes (no access to the storage device necessary) and single points of access to storage devices.

• Future setup

The future setup, i.e. native Akonadi support, looks almost like the migration setup when being abstracted like in the diagram.

The differences are now mainly how the applications can handle the contact data internally, e.g. they are no longer limited to keeping copies of all addressee objects at all time, KAddressBook no longer needs to check which addressee objects to upload to the Akonadi server since it can now upload them individually right after modification.

That's all for now.
I am going to write a second part about migration options for data access facilities. Until then stay tuned through Danny Allen's awesome Commit Digest

No, the title is not recycled from my previous blog entry but it is very closely related.

Last time I wrote about Akonadi based KResource plugins, this time I am writing about KResource based Akonadi resources.

Since both entries are rather targeted at other developers, I promise to write a third one explaining the things from a user's point of view

But now back to the topic.
In order not to lose all the work put into the KResource implementations for various backends like popular groupware servers, it is basically a necessity to provide a bridge using these implementations to get data from their respective backends into Akonadi.

Akonadi uses a special variation of its clients, called Akonadi resources, to provide loading and saving on some external storage, e.g. local files, remote files, groupware servers.

The two new resources, called KABCResource and KCalResource use KABC::AddressBook and KCal::CalendarResources respectively to access data provided by an appropriate KResource implementation.

Again, similar to my other compatability implementations, I haven't tested it very thoroughly yet, but loading from a local vcard or calendar file, saving at resource shutdown and reacting to changes in the file's data should already work.

If you'd like to help testing, both resource can be added as usual through akonadiconsole, where they are called "Akonadi KABC compatability resource" and "Akonadi KCal compatability resouce".

As their configuration step they'll open the usual KResource selection dialog which allows to select their KResource backend, i.e. the actual data access implementation.

Any feedback appreciated!