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.

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.

Well, not yet.

I am currently at Graz airport, about to begin a journey to Austin, Texas, where I will be attending the Linux Collaboration Summit.
Special thanks go to the Linux Foundation for covering my travelling costs and KDE e.V. for the hotel, specifically Ian Monroe who took the burden of doing the hotel reservation.

Ah, right. Houston.
The summit takes place from Tuesday to Thursday, however I am not returning until Sunday. Interestingly any return flight earlier doubles the fair, so I basically have to stay two days longer
My plan is to a day trip to Houston and visit the Johnson Space Center there, though I have still to figure out how to get from Austin to Houston and back again.

Anyway, boarding will begin soon (hopefully).

Based on reactions to my previous blog entry I'd like to add a bit of context regarding the GSoC idea of implementing a GLib/GObject based client library for Akonadi.

The whole architecture of Akonadi is based on the idea not to depend on any specific library but to make the data storage access protocol, and D-Bus for out-of-band notifications, the only requirements for clients.
Learning from the non-adoption of DCOP and KIO, both also out-of-process service infrastructure projects, due to the lack of visible alternatives to the respective KDE based client libraries, the developers of Akonadi acknowledge the need to at least a second, independent, client library implementation.

This could of course be done in Java or Python, but since the GLib software stack is one of the two main stacks for Free Software desktop applications, it sounds a lot more reasonable to use it for the first of hopefully many means to access data in Akonadi.

Some people understand this to attempt replacing the Evolution Data Server.
Of course a GLib/GObject based client library for Akonadi would make it an second option for application developers on that software stack, but I am pretty sure that the EDS developers have enough confidence in their technology to not be afraid of the partial overlap between the two projects.

But just in case they want to strengthen their position and are looking into hosting a GSoC project for developing a Qt/KDE based client library for EDS, I'll be available as a co-mentor on Qt/KDE specific issues.
Btw, for this is would be great if the EDS maintainers could put the D-Bus based communication back on their roadmap.

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!

I just moved the two Akonadi KResource "bridges", i.e. implementations of the KResource plugins for contacts and calendars based on Akonadi (KABC::Resource and KCal::ResourceCalendar respectively), to kdepim/kresources.

If you are intersted in testing them, you need an Akonadi setup with at least one resource for the respective data type, e.g. an Akonadi vCard resource for testing the kabc plugin.
Run akonadiconsole to check and/or add such resources and it would probably be wise not use valuable data

Adding the bridge plugin to an application works just like adding any of the already existing ones, e.g. for the kabc resource you can fire up kaddressbook and then use its menu "Settings -> Show Extensions -> Address Books" to get a list of activated contact resource plugins.

Then click on "Add..." and you should see the resource named "Akonadi" right on top. Adding it (or clicking on "Edit..." later on) will show you a list of Akonadi contact collections. Select the one you want the resource plugin to access and click "OK".

Works pretty much the same for the kcal plugin in KOrganizer.

Btw, if anyone knows what I am doing wrong in the resource configuration widget, i.e. why it doesn't correctly pre-select the collection on "Edit", please let me know.

If you are an application developer using KABC::StdAddressBook or the KCal equivalent, you'll probably need to edit the respective stdrc config file to make the Akonadi resource the default.

Since my experience is mostly KABC related, I'd like to ask especially developers using the KCal APIs for feedback.

But now, back to watching the Atlantis ISS docking on NASA TV

Meanwhile I have switched the Cafe to one inside the security area and from Cappuchino to Schneider's Weiße

One import think about KDE developer meetings is that they are not only about getting work done, but also about getting to know each other better.

Additionally to the usual "mapping faces to IRC nicks" happenings which one can also experience at our big events like Akademy, this is also about meeting people who build successful businesses upon our work, in this case the people from Intevation.

Aside from hosting the event at their office and sponsoring our dinner on Friday (including many beers ) they are totally cool guys and talking with them is both enjoyable and enlightening. In a world where vendors of proprietary products dominate the view customers have on software, it is an exceptional achievement to be a successful competitor based on Free Software.