Saturday, 20 December 2025
@vkrause:kde.orgLast weekend I attended the annual(ish) KDE Personal Information Management (PIM) sprint in Paris, to discuss and work on KDE’s infrastructure and applications for dealing with email, calendars and address books. And since this involved travelling, there was some Itinerary field testing as well of course.
PIM Sprint
The PIM sprint was hosted by enioka Haute Couture this time, in their offices in the middle of Paris, which happens to be located in a very appropriately named street for this.
With nine people attending (even if Kévin could only make it remotely in the end) it was actually a new record since moving that event to France many years ago. Even better, for about half of the attendees it was their first PIM sprint ever.
Topics
The following is by no means complete, see also the other reports on Planet KDE such as the one from Albert, as well as the notes on the sprint wiki page.
KMime framework
My focus was mainly on finally pushing the move of KMime to KDE Frameworks over the finishing line. While most review comments collected during Akademy have meanwhile been addressed, the request to make ownership transfers more explicit in the API is still requiring work. Not so much in KMime itself, but it’s exposing sloppy ownership semantics in consumer code such the message composing code in messagelib. Attempting to untangling that has at least already lead to multiple memory leaks being found and fixed.
Message-IDs
We also reviewed the code to generate Message-ID headers in KMime, triggered by a recent
forum thread.
Message ids have to be globally unique, but the underlying specification
and implementation predate UUIDs being widely available (yes, email is that old). Therefore this used
to be a combination of a time-based random string and the host name of the sending machine.
That works but is not up to today’s privacy standards anymore. Instead, the de-facto standard nowadays is to combine a UUID-based identifier with the domain of the sender address. The latter is just necessary to comply with the format and doesn’t contribute to the uniqueness. KMail will now do the same.
While that is a minor detail, it’s somewhat symptomatic for working on email-related code, trying to understand decisions made in specifications and code from last century and assessing the implications of changing any of that.
And more
Other topics discussed included:
- Retirement of the Kolab resource. That has been on the agenda since years, and a proposal exists since a while. That hasn’t been implemented yet in the hope for a better solution which never materialized. Meanwhile a library this depends on is no longer buildable on current systems, so the Kolab resource has been silently disappearing from some distributions already, which is far worse than even the most low-effort orderly retirement.
- Flatpak packaging for the Akonadi stack, and the challenges for host integration that come with it. As sharing that between two Flatpak applications and/or to/from the host isn’t really viable, the best we can do is probably a dedicated D-Bus interface for a separate platform calendar backend plugin in KCalendarCore, and use that for host integration like in the Plasma clock.
- Improvements to address auto-completion in KMail, in particular better defaults for filtering “no-reply” addresses.
We also spend some time debugging some weird synchronization issues that David R eventually tracked down to a very recent one-line change. This originally had been mis-attributed to the Sqlite backend for Akonadi while exploring whether that should become the default (with support for the other databases being dropped in the long run), but fortunately turned out to be entirely unrelated to that.
Travel
Travel ended up a bit adventurous and thus provided plenty of opportunity for observing Itinerary and Transitous under unusual circumstances.
- We need a more powerful alternative journey search that doesn’t use the next change as a starting point, but every upcoming stop of the train you are currently on. MOTIS used to have this built-in as so-called on-trip queries, but it would also be possible to emulate this client-side. This helps with situations where the best alternative isn’t just to take the next train after a missed connection, but to continue on the train you are on longer to connect onwards at a later stop.
- We should apply a lower-bound sanity check to realtime data in Transitous. In cases of more complex reroutings and detours Deutsche Bahn’s own projection can contain times which go beyond what’s technically, legally or physically possible.
- Also, crowd-sourced vehicle positions are equally valuable for operators where we usually have realtime data, to further support such sanity checks. Deutsche Bahn’s onboard GPS is actually precise enough (outside of tunnels) to determine the exact track (and thus the speed rating) on OpenRailwayMap.
- Border points reported as dummy intermediate stops without a time or location still slip through on some backends and mess up our progress display in Itinerary.
- Parsing of international DB seat (re)bookings got fixed.
Another interesting observation from a routing perspective were passages in Paris (e.g. Passage Jouffroy or Passage des Panoramas) which in OSM terms are essentially footways with opening hours or conditional access. That is, those work as regular pedestrian ways during the day and are closed at night. OSM can model this for roads and routers can usually deal with that for vehicles, but I haven’t seen this used yet for walking.
You can help!
Getting everyone together for a few days is extremely valuable and productive, and your donations to KDE .e.V. help to make that possible!
ngraham
