KDE PIM/Meetings/Osnabrueck 6

From KDE Community Wiki

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.

Agenda

Friday

17:00 Kick-off

19:00 Dinner

Saturday

9:00 Start

12:00 Development tools tutorial

13:00 KDE PIM on Windows

15:00 KDE PIM in KDE 4.1

16:00 Akonadi

19:00 Dinner

Sunday

11:00 Closing and Outlook

Meeting Minutes

KDE PIM 4.1 Plans

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:

  • Stable release of all applications (including Kontact, KMail, KOrganizer, KAddressbook, and all the other KDE PIM apps) ported to KDE 4
  • Applications will still use the KResources framework
  • Merge of all the features of the enterprise branch
  • Initial release of the Windows and Mac OS ports of KDE PIM

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.

Akonadi Discussion Notes

Move libakonadi and at least libakonadi_kmime to kdepimlibs. We'll probably have a meeting in March to do API reviewing/fixing for that.

Feedback by current users

  • Cache policies are missing, only a complete fetch of all folders is currently possible, see below.
  • There is no way to set and retrieve the size of an item, neither for the current item size nor for the full item size reported from the backend (supported eg. by IMAP, POP3).
    Proposed solution: Add generic item property to set/get the size, unless an extra item part this allows server side support for e.g. determining the folder size.
  • Item internal add date: Hm, I don't remember why this was needed, but it's basically there already in the server and just needs to be exported in the client API.
  • Support item streaming in itemsync.cpp to avoid keeping all items in memory, which is especially a problem for non-incremental snycing.
  • Add API for type-safe access to additional item parts (those not covered by the payload), similar to what we have for collection attributes.
  • Configuration handling. Currently resource agents show their own config dialog on request, there is no way of integrating this into an application dialog or eg. implement a wizard.
    Proposed solution: Embedding of resrouce/account configuration is not used by any current application, all use separate dialogs. So, we don't need to change that part, except for adding a parameter for the parent window id to the method to fix the usual window management problems with out of process dialogs.
    Additionally we'll add an interface to set and retrieve single config settings from the resource, using a string key and a variant value. ResourceBase will implement those methods and map them to a KConfigSkeleton (KConfigXT generated code) for convenience. This will allow configuring resources from external applications such as wizards or migration tools.
  • Showing additional dialogs (eg. password request) from resources: Add a method to ResourceBase to request a parent window id for them. Additionally add a systray icon (eg. to akonadi_control) to have a hook into the GUI for the background processes to show status, progress or error messages etc.
  • Limiting ItemFetchJob to data in the local cache is still not possible, causing a full download of everything if any search index feeder is running.
  • Conflict detection: We might need a convenience API for resources to remember the last seen revision to be able to detect conflicts when writing changes from the backend to Akonadi.
  • The API for collection and item modification jobs is really broken, telling the job again is way to cumbersome.

Cache policy requirements

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:

  • The item parts that should be permanently kept locally and are downloaded during a collection sync (eg. full mail vs. just the headers).
  • A time up to which non-permantly cached item parts have to be kept at least (0 - infinity).
    [Do we also need a size limit for the cache as well?]
  • Wether or not a collection sync is triggered on demand, ie. as soon as it is accessed by a client.
  • An optional time interval for regular collection sync (aka interval mail check).

This has been mostly implemented during meeting, together with the necessary interface to only sync a single collection.

Nepomuk integration

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 ;)

Blogs

Retrieved from "https://community.kde.org/index.php?title=KDE_PIM/Meetings/Osnabrueck_6&oldid=10431"