The Akonadi framework is responsible for providing applications with a centralized database to store, index and retrieve the user’s personal information. This includes the user’s emails, contacts, calendars, events, journals, alarms, notes, etc. In SC 4.4, KAddressBook became the first application to start using the Akonadi framework. In SC 4.7, KMail, KOrganizer, KJots, etc. were updated to use Akonadi as well. In addition, several Plasma widgets also use Akonadi to store and retrieve calendar events, notes, etc.
All I really need is KMail & KAddressBook so I’ve been removing other Akonadi applications in an effort to make this whole unstable ediface less crash-prone. However there are still 18 Akonadi processes running, all of which presumably want to fiddle with the database.
Does anyone have any insights in how to simplify the default PIM installation? Can I just get rid of PIM altogether if I migrate to some other email client?
I have strong doubts re. this optiimization technique . I’ve been a long time Kontact user and yes, I’ve had crashes in the past. But the last couple of years it has been a stable experience.
However there are still 18 Akonadi processes running, all of which presumably want to fiddle with the database.
akonadi opens the database, but nothing happens to the database unless there is a need for it. If an agent has not configuration it will not fiddle with the database. I would object to this if I would see memory leaks or high CPU usage, but I don’t. This with 12 IMAP accounts, ~200K of emails
Does anyone have any insights in how to simplify the default PIM installation? Can I just get rid of PIM altogether if I migrate to some other email client?
Why get rid of it, instead of simply not using it?
Does anyone have an opinion on Evolution?
David L.
Evolution is a great suite as well. Used that a lot as well. But it will pull in a lot of GNOME stuff.
If you want to be more independent, make sure not to use the patterns packages.
When Kmail works, which it does most of the time, it works well, that’s the frustrating thing! I like the flexibility of Kmail’s filtering, particularly the ability to use regular expressions and rewrite headers, the flexibility of it’s UI configuration, and its search capability. For example, I have filters which rewrite flowed-format bodyparts into a proper format which restores proper quoting, even when encoded base-64.
But when Kmail fails it really gets itself into a knot, and recovery can take a lot of time.
I’ll probably stick with it for now, but I’ve configured Thunderbird as a backup.
However I still think the PIM suite needs a software review with the object of making it more reliable (are there race-conditions and program-lock problems?), and making the whole suite more modular at run-time. Its modularity now seems to lie mainly at the user front-end, with the underlying complexity pushed back into Akonadi.
IMHO, only because errors are usual treated as being fatal rather than, handling any errors which occur as something which may occur because, the data being received, «the e-Mails», has been created by «something else» – which is often not perfect …
IOW, yes, the received data may have some issues but, just because whoever it was who sent that data «didn’t adhere to the rules», doesn’t mean that, one should error and give up – it may be ugly, with warts and carbuncles and smelly and whatever but, that’s no reason to error and simply give up …
I think (a) applications should not be data-sensitive, and (b) many Kmail problems are pretty clearly not due to data anyway.
A few hours after posting my last response, Kmail failed again with the syndrome whereby a received message has two entries in a folder (normally Inbox), but one is in blue and cannot be deleted or moved. akonadictl reported:
Looking for dirty objects...
Collection "Search" (id: 1) has no RID.
Found 1 collections without RID.
Found 0 items without RID.
Item "31785" has RID and is dirty.
Found 1 dirty items.
Dirty entry is an entry which has been modified locally and has to be updated in the remote storage (like IMAP server of Google Calendar). If you have dirty items locally and all resources are online, then it means that the resource probably failed to store the change on the server. Currently we unfortunately don’t have any mechanism to make Akonadi to try to sync the dirty items again. There’s a fix for that in the pipeline, but no promise on when that will be implemented.
No fix after almost three and a half years?
Another problem whereby Kmail fails to start the filters reliably also remains.
Surely the developers should focus for a while on finding & fixing bugs rather than introducing more bells & whistles!
. I’ve been a long time Kontact user and yes, I’ve had crashes in the past. But the last couple of years it has been a stable experience.