[Kde-pim] KDE PIM/Akonadi Meeting at Akademy

[Volker Krause]

Hi,

we had a meeting here at Akademy to discuss our plans for 4.2. The notes are 
attached (mainly done by Ingo, slightly supplemented by me).

The most important decision is probably that we want to deploy Akonadi for 4.2 
for calendar and contact data. This is primarily done using Kevin's Akonadi 
<-> KResource bridges, which avoids the need to change anything in the 
applications and the backends. It will introduce overhead and likely new 
bugs, but it allows us to port applications and resources in small pieces 
instead of breaking everything for an extended period of time.

regards
Volker
-------------- next part --------------
KDE PIM/Akonadi BoF

Agenda
1 Akonadi feedback
2 KDE PIM planning for KDE 4.2
3 Akonadi planning for KDE 4.2

1 Feedback

Tom (Mailody)
- problem that nobody is using it
  -> bugs are not found/fixed
- small features missing: item size, ...

Bertjan (KPilot)
- ical/vcards backends are not working reliably

Dmitry's wish list (RSS GSoC)
- redo item sync and probably also collection sync
- fetching items filtered by important properties (e.g. all contacts)
  -> correct solution: virtual collection
  -> fetching by mime type is needed eg. for stuff like KABC::StandardAddressbook
  -> fetching by remote id
- intermediate solution for searching:
  -> fix Nepomuk agent
  -> directly use SPARQL queries
- add collection id to itemChanged() signal
  -> can be added, but will require lots of changes in observer API and other APIs
  -> no high priority, collection can be encoded in item remote id
- possibility to add items to virtual collections (similar to hard links)
  -> will be needed for "search in resource" functionality


2 KDE PIM 4.2

Do we want to port KAddressBook and KOrganizer to Akonadi for KDE 4.2?

Problem: KAddressBook/KOrganizer assume all data is in memory and all access is synchronous.
-> Porting is a huge effort (make all data access asynchronous, use monitoring)
-> KOrganizer (in the UI code) explicitly assumes calendar resource.
-> Initially (for KDE 4.2) use the resource bridges.
   -> still some work needed in the bridges to support sub-resources
   -> existing native backends (ical/vcard) need some work: robustness, support remote files, support legacy formats, etc.

Conclusion:
We will go for the bridge based migration. This causes no actual change to existing user data and settings unless the migration tool run, giving us an "emergency stop" option to be used in case the bridges and/or the migration tool are not ready for 4.2.

- Error handling in apps if Akonadi server is not present needs to be added.

People who want to help should
- Focus on making the current Akonadi resources and the bridges work.
- Focus on converting the old KResouces to proper Akonadi resources.

The applications (KAddressBook/KOrganizer) should not be ported before Akonadi is really stable, to preserve the emergency abort option mentioned above.

An Akonadi meeting is planned for early November, before the hard feature freeze for 4.2, likely the point where we will decide if we want to commit to the migration for 4.2.

For KMail:
- Split/refactor into components.
- Port components one at a time.
- For 4.2: Use header view (from SoC project).
- Not much else happening there for 4.2.


3 Akonadi 4.2 planning

-> see wiki page with tasks, main focus are resource bridges, migration tools and solving the current deployment issues
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080815/70f22b26/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/