One of the weakness of many useful KDE apps is its requirement for Akonadi server, because no matter how many times I attempt to use some of KDE PIM apps like KOrganizer, KMail, KNotes… they cause serious and catastrophic problems at certain time due to failures from that broken server, they can never be trusted for professional usage.
We really need a new alternative to it, because its integration is deeply forced in many apps that rely on it, like the new Kalendar.
That’s not going to happen like that, for a few reasons:
First Akonadi has very little do to with Plasma, let alone with its major version, so “for Plasma 6” is not relevant when discussing Akonadi.
Then assuming someone were to write a “new Akonadi” from scratch (which nobody is lining up for) it would be likely a multi-year effort to get anywhere close to the kind of functionality we have today, and there is absolutely no guarantee that the end result would actually be better.
It’s installed by default with every distro that ships full KDE Plasma.
there is absolutely no guarantee that the end result would actually be better.
For now, Akonadi is one of the components that are confirmed to be broken, so any attempt to rewrite an alternative would surely give the same or even better result.
Akonadi has bugs this is true but rewritting it from scratch won’t make these bugs go away. The issue with Akonadi is a lack of developers (but this improved a bit a few months ago) and groupware solution are very hard problem to begin with.
Things like email have more than 30 years of legacy baggage. To have something functional, you need to support a lot of different providers all implementing the ‘standard’ in a different ways, if they even try to support the standard (thanks google for creating your own apis for everything).
If someone wants to improve the pim stack, there are a lot of easy things that could be fixed without having to rewrite anything. The code base is for the most part actually quite clean with a lot of API doc and unit tests.
To have something functional, you need to support a lot of different providers all implementing the ‘standard’ in a different ways
The best approach is to deprecate (or remove) support for least used providers and focus on popular ones like Google (most used by companies) and Microsoft.
Although I too think it is not necessary to start Akonadi from scratch, I also think that the current state is unusable. But not in a “oh what a shame I can’t use this” kind of way…
It has happened to me that when I first tried KMail, akonadi was installed as a dependency (of course), and from then on Plasma would randomly crash (like every five minutes or so). It was a while after, upon reviewing journalctl for days, that I discovered it was akonadi crashing the desktop. I uninstalled it and everything went back to normal.
If I was a normal user, I would have thought that the Plasma is unusable and an unstable mess.
This bug is probably not present anymore (this was some time ago), but it also was not the only issue/tribulation I had with Akonadi.
The bottom line is that Akonadi in its current state is not usable, cannot be recommended and needs a lot of work. Thus, a decision has to be made: Does KDE want to fix it or not?
If KDE does/can not dedicate resources to fixing the PIM stack, then I would suggest to stop recommending KMail, KOrganizer, etc. They are not usable right now (experience may vary, but it’s unquestionable that the PIM stack is not stable enough for the mainstream public).
To be clear, I do not want this to happen, but I also don’t think that shipping these things in the current state is beneficial for the image that KDE and Plasma are trying to project. Like it or not, Akonadi IS a part of KDE (regardless of ownership) and should be treated as such.
PS: Sorry if this came out as passive-agressive, I’m just very passionate about this topic due to the issues I encountered . I would love that the Akonadi project had more resources to fix the issues they have.
I don’t think this makes any sense, if a provider works then there’s no reason to remove it. Akonadi providers (the parts that provide “Gmail”, “Google” and “IMap” accounts) work like plugins, they don’t affect each other. That’s of course, an oversimplification from the outside as I don’t work on the PIM stack
Deprecating old and unused parts or plugins will help to clean up the bug tracker and focus on urgent tasks that need to be completed.
Akonadi is treated as the hardworking employee at the center, where every PIM app throws those complex requests to be finished by the server, this made Akonadi too much complex, and the devs effort is divided on some old unused parts instead of focusing on most used services.
You’re kind of telling what should be done, and devs don’t seem to agree. No one is saying hat Akonadi doesn’t have issues and it’s good to brainstorm on other approaches but then it’s important to listen to what they say, unless you are yourself a more experienced dev cpable to demonstrate where they’ve got it wrong, and ideally are willing to work on it.
This isn’t true, neither KDE Neon, nor Kubuntu (minimal) install Akonadi or any of the KDE Pim by default. This is one of the reason I use them, as I also think that sadly KDE Pim has too many issues and so I don’t want it installed (that said I am now using the new Kalendar - forgot the new name - app).
Don;t see this thread as a shut down of your ideas, but also understand that the devs are those doing the work and understand the subtitles of how the software work, and so having “random Joe’s” telling them you should do this and that s not always constructive especially when they take the time to respond and explain why they don’t agree.
I’d rather tell people to stop using services from Google and Microsoft as they are the bigger standards-breaking email providers.
Any company here uses Google Business Suite/Workspace (with customized @companyName.com) as their primary service for mails, meets, planning, online documents’ collaboration…
@guss77: Please check the mailinglists for PIM-Users: Discuss and Bugs
I like KDE really much, but stepped away from any application, that needs AKONADI, Sorry to say that …