Venue

Etincelle Coworking Carmes - Baobab room
1 rue Bouquières – 31000 Toulouse - France
https://staging.etincelle-coworking.com/toulouse/carmes/salle-baobab (website in French only)

Agenda

Add topics we should discuss:

Revisit the Tag support in Akonadi resources (current situation is fairly broken, tags from payloads are not usable anywhere)
How can we get rid of the mimetreeparser fork?
Windows build of gpgme-qt6
How to finally retire the Kolab resource
Status of notes (KJots/KNotes)
Getting KMime ready for a move to Frameworks, identifying more classes to move to Frameworks.
Akonadi Sqlite locking issues
Mobile specific issues:
- Move resources configurations to QML
- Sliding sync in Akonadi
Move libkdepim/src/multiplyingline to frameworks
E2E testing of resources
Project Goals

KJots was deprecated a long time ago and removed from releases, but people kept shipping it
Only actually working backend was the local maildir backend, which could be importable in e.g. Marknote from that, so we have a data recovery pass.
- This has to be done before we remove anything.
The same approach will work for KNotes.

There's secondary notes integration (Add Note/Create Note in KMail for example), not all of that is using Akonadi note item types though and are actually unrelated and use Akonadi attributes or IMAP annotations.
Following from that we can also remove the akonadi-notes repository.
This means also the akonadi-notes resource will go away (see issue below for undeletable resources), same problem already exists for the removed Tomboy resource as well.

Akonadi isn't prepared for agent binaries disappearing and agents for that still being configured, up to the point it might not even be possible to delete that anymore. Should be fixed before finally removing the resource.
Possibly needs a list of dead resources in Akonadi to do this safely.
Automatic migration is considered technically unfeasible due to no way of getting the magic URLs for DAV.
Needs 1+ year pre-warning time before final removal.

For porting to the new version that needs to catch up on features that were removed there, such as the plugins
- We can't really avoid plugins here, as we otherwise can end up with cyclic dependencies (e.g. via akonadi-calendar)
- The existing plugins need to be ported, and either be built-in or being plugins
- HTML rendering is not included

Can we use the new QML/widget renderer instead of the status quo HTML renderer?
- That means all the HTML security problems go away, and we can do proper incremental updates
- We'd lose some of the styling features, but those are mostly unused anyway?
- Header customization could be done via settings, rather than by custom styles.
- Adblocker etc depend on webengine, so that could continue to work in html parts of the new renderer (which also uses web engines)

Problem remains with Sqlite, and is rather due to Akonadi's overuse of (long-living) transactions, not specifically a Sqlite problem
Sqlite's table-level locking makes this worse though.
With Sqlite we need to manually do transaction replay on failures.
Item sync can be optimized to need less long-running transaction, see Dan's client-side item sync branch.
Client-side transactions need to go anyway, as that makes connections state-less and would remove the need for per-connection threads.

sliding window sync isn't even the biggest issue, partial downloads is the bigger problem
sliding window sync also needs a fetch more action when scrolling down
needs expanded cache expiry to also drop items rather than just content
resources need to be aware of that, otherwise they download everything
- only needed for IMAP (DAV has this)
assuming we have sliding sync, how do we represent this on desktop?
common infrastructure, or IMAP specific setting?
- we at least need a common "fetch more" API
we need collection locking to prevent cache cleaning while user is looking at content
count-based or date-based? count-based is easier, date-based needs mail content knowledge inside Akonadi core
also related: remote online IMAP search
- would need a separate search result collection? virtual collections don't work for this
- all existing search infrastructure assumes local existence, so we need something new here
expire policy could also consider unread flags
collection stats wont work as such, if we need it that would require online IMAP query

--> defer this until we have a more advanced mobile client

turn agents into core applications, for possibly merging those into one back process (blocked on config and message box error messages)
refactor the resource UI to be out-of-process QML
- some resources are ported
- IMAP is tricky due to having a server connection for feature discovery, that stuff needs to move accordingly
- EWS also needs to ported
- agents also have that problem
how does this relate to account wizard?

removing message box based error handling
- tricky for the copy/paste case, notifications are not ideal for this case as we lack context there

MS wants to kill this, deprecated in the next 3 years (unless they change plans)
graph API is supposed to be the replacement, we have no support for that yet
access to test accounts is tricky, g10code has one at least
need for EWS support reduced now that we have XOAUTH support for MS IMAP
short term: fix the current issues, but longer term probably not viable anymore

June 15/16, 2024
It's encouraged to show up to the venue on the Friday 14 June afternoon
Kevin will be there after lunch on the Friday to greet the early birds, work can be started when enough people show up

Plenty of options in the area on all price ranges, living there I didn't get to try them though...
Proposed hotel is "Hôtel Croix Baragnon": https://www.hotelcroixbaragnon.com (also available through booking.com for those who prefer that)
It's really really close to the venue, probably the closest hotel actually
Simple room are 75€ per night, twin rooms are 98€ for those who don't mind sharing space
They still seem to have availability at time of writing

Carl arriving on the 13 June at 18h (airport)
Dan arriving to TLS on Friday at 13:55 (LH1096), leaving on Sunday at 17:50 (LH2221)
Volker arrives by train Friday 10:38 leaves Sunday 18:16.

To be announced

To be written