Akademy/2026/PIM BoF

When? Where?

It will be in two parts:

TODO

Ingo as the oldest serving PIMster declares the PIM BoF open.

This covered the STA-funded work the Enioka team is doing:

End-to-end test for IMAP/DAV and iTip infrastructure (ont testing the app, just Akonadi and everything below).
Protocol extensions for IMAP and DAV (IMAPrev2, DAV push).
Account auto-configuration.
Flatpak packaging of Kontact (access to individual apps, Plasma integration).

Tests are good, how to keep this going in the long run?
Meanwhile these tests run on the KDE CI, in theory.
Was running reliably but taking long, got worse when optimizing this. Also, affected by a KWallet behavior change/regression.
Best case this gets fast enough to be a downstream pipeline of DAV/IMAP/Akonadi, ie. this doesn't run on a timer but runs on changes in those repos.
Tests can also run locally, on an isolated Akonadi instance and with containerized servers. One remaining problem is KWallet, which is not isolated. Another challenge: this needs PySide.
Code is about 50% tests and 50% test harness.
Running parts of the tests is possible to speed up local runs (e.g. DAV-only/IMAP-only, or just one server variant). Selection happens via PyTest.
Another maintenance aspect: updating the server containers.
Probably more value in adding more test scenarios rather than adding more server variants.
Radicale is very strict on the spec, Nextcloud is very relaxed.

DAV resource was in a less good shape regarding tests etc, making larger changes harder.
Resource was migrated away from the deprecated Akonadi Observer API.
Push notification support, allowing to sync on demand rather than by polling.
Polling still need to happen, but can use a much longer interval, and can be pushed back when push notifications come in.
Added support for the sync token extension, allowing for incremental sync, increasing sync performance.

How does this related to the online account infrastructure?
Account view vs. the detailed resource/identity/mailtransport view in Kontact.
Application access to the online account infrastructure requires user permission.
New library being developed, still in a personal namespace. Should this go to PIM or KF? Will be used by KMail account wizard and the online account stuff. Release model for online accounts is still undecided.

Support starting individual apps rather than Kontact as well.
Isolation issues between host and Flatpak data, due to full file system permission.
Host and Flatpak integration for contacts/calendar, to be addressed by a new D-Bus API for this, not importing/exporting the Akonadi service in full.
- can we connect all this through the KF::CalendarCore plugin system? This has a slightly larger API surface than what would be needed just for the Plasma integration
- a similar plugin system exists as a draft MR for KContacts - https://invent.kde.org/frameworks/kcontacts/-/merge_requests/68
- there's overlapping work as part of two other grants from GNOME and KDE
- The Plasma plugin system also has a backchannel to view events, the proper solution is XDG Intents, might need a shortcut due to project timelines via a direct D-Bus call for now.

Someone actually needs to do this.
Reach out to current users to understand what they use.
Reach out to former users and find out why they stopped.
- From Kevin's colleagues: calendar data not synced, caledar list recreation, issues with recurring events.
- From attendee: Mail receiving/sending/identity setup is too complicated and spread out.
- From attendee: IMAP sync stops and needs an Akonadi restart. (probably network status related, we see this in other applications as well)

KMime is now in KF
KCalUtils is being removed with 26.12
KImap for KF next
- move could happen right after stable gear branching
- this time also rename the translation catalog then, that's what broke co-installability for KMime