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.
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.
The following image shows the three setups side by side:
The traditional setup is based on plugins we developers refer to as KResource framework.
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".
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.
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.
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.
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.
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.
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.