The annual KDE PIM Meeting Osnabrück 6 took place at the Intevation offices in Osnabrück from Friday, February 1st 2008, to Sunday, February 3rd.
12:00 Development tools tutorial
13:00 KDE PIM on Windows
15:00 KDE PIM in KDE 4.1
11:00 Closing and Outlook
We had a discussion about the plans for KDE PIM in KDE 4.1 at the Osnabrueck meeting and came up with the following:
KDE 4.1 will be released in July, feature freeze is end of April. This will include KDE PIM as the first KDE 4 based release of KDE PIM. We plan to include the following features:
The plan for Akonadi is to make KDE PIM 4.1 the Akonadi Platform release. That means that libakonadi and the required infrastructure is moved to kdepimlibs, so that third-party applications and resources can be developed based on Akonadi.
This also will be the base for an incremental port of the existing KDE PIM apps to Akonadi. The goal is to do this in trunk by refactoring the existing applications, but keeping the apps stable.
The KDE 4 version of Mailody already uses Akonadi. It's the first full application which makes use of the new backend infrastructure. Mailody is likely to be released once the Akonadi Platform is available in a stable version.
To make migration easier there also exists a bridge which makes Akonadi data available through the KResources framework. It might be nice to also implement an Akonadi agent who can talk to the old KResources.
There are also first Akonadi resources and plasmoids in playground. We hope that more of this will emerge as the platform gets more stable, complete and available.
The long-term mission of Akonadi is to provide a cross-platform cross-desktop storage service for KDE PIM data. So it's not meant to be limited to KDE. APIs for other environments or other programming languages than C++ are very welcome.
Move libakonadi and at least libakonadi_kmime to kdepimlibs. We'll probably have a meeting in March to do API reviewing/fixing for that.
Cache policies are supposed to specify which data is kept locally, for how long and how/when it is downloaded. We came up with the following requirements which should cover everything we have up to now:
There is one cache policy per collection, it can either define to inherit all properties of the policy of the parent collection (the default) or specify the following values:
This has been mostly implemented during meeting, together with the necessary interface to only sync a single collection.
The new idea for implementing searching is the following:
For every mimetype there will be a nepomuk feeder agent, which listen to all available collections and as soon as an item of the monitored mimetype is added or removed, it will extract all meta data and push them into nepomuk storage via Soprano (Qt-only DBus interface).
For searching the data we'll introduce a new daemon (queryserver) which provides a DBus API to Akonadi and uses the Soprano API to access Nepomuk. That daemon emulates a XESAM-like service (e.g. persistent searches), however its query language is SparQL instead of XML and the API is object oriented.
The XesamManager in Akonadi will be renamed to SearchManager and adapted to make use of the queryserver.
The functionality of queryserver might be integrated into Nepomuk later, so see it as a rocking temporary solution ;)