Last 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.
Regarding Akonadi and Flatpak: I think the best approach is to run the service on the host side and expose it to the app sandboxes, just like this is done on other platforms, e.g. Android’s calendar.
Obviously that only works on KDE centric setups, e.g. this would be expected on KDE Neon, KDE Linux or Fedora Plasma Desktop.
The Flatpak apps would still need to be able to start their own instance as a fallback if the host does not provide it.
Users could be advised that they get account/data sharing between apps and desktop integration if they go for the recommended setup.
Right, as Akonadi was designed as a platform service, that’s where it’s placed best. There’s no “calendar portal” yet though (unlike on Android), so getting that back into the sandbox is currently essentially the same problem as getting it out from there. So anything built for that will help both cases. And we have apps that needs that either way, e.g. Itinerary which can make use of a platform calendar but where it makes absolutely no sense to provide its own calendaring infrastructure.
Sharing accounts is part of Nico’s work on the new online account infrastructure.
I was mostly thinking about “exporting” the Akonadi socket just like the X11 and/or Wayland socket.
So there should already be code in either flatpak or something related which does that.
The D-Bus interface could probably also be registered with that of sandbox as the portals do that.
Potentially we could have a sort of proxy so that the actual Akonadi server is not directly exposed to the sandbox, i.e. like the portal frontend/backend split.
But I would consider this a secondary step.
Right, I was thinking in terms of Akonadi resources here, e.g. E-Mail account/folders
While technically probably possible, the main challenge with that approach is that we have no proper compatibility guarantees on the protocol anymore (since the 5 era IIRC), that would need to be re-established first.
Ah, I see. I had not realized this had changed.
With traditional distributions this wasn’t much of an issue since you could just install their packaged clients but there seems to be a trend toward immutable system + Flatpak