[kdepim-users] rant
René J.V. Bertin
rjvbertin at gmail.com
Wed Jan 28 10:12:49 GMT 2015
On Wednesday January 28 2015 09:37:47 Werner Joss wrote:
>p.s.: currently I'm still using kontact as my primary pim-suite, for reasons
>you also mentioned.
>but, when friends ask me to help with an open source email/pim suite, I do not
>dare to recommend kdepim to them, but thunderbird/sunbird instead.
But thunderbird is more or less an orphan these days, no?
Myself I consider KDE PIM mature enough to replace Apple's Mail.app on OS X even though platform integration isn't perfect out of the box. But my recommendation would be to use the 4.13.3 series in combination with the latest akonadi release. At least on slow(er) hardware the 4.14.3 series was much more inclined to get stuck retrieving email, and/or run into the simultaneous connection limit gmail imposes.
It also pays to take a moment to set up akonadi to use mysql instead of sqlite3 (which doesn't scale well), using e.g. the mariadb mysql server instead of the one shipped by default (on Ubuntu). Postgresql is even better apparently but seems more intricate to get up and running - I haven't tried.
As to the offline mode: it's not a binary choice. Each IMAP folder can be configured to cache contents for a specific amount of time, which means the extra wait applies only to the 1st download. Set this up correctly, and you'll have to wait only for email that you consult very rarely, i.e. when those couple extra seconds are moot.
I'm not sure I agree with the akonadi principle though. It seems overly complicated and intricate. If the goal was to avoid a huge swiss-army does-all PIM tool, that has been missed blatantly IMHO. You just don't notice it (unless you fire up Kontact). The only advantage is that a crash in one of the helper components doesn't bring down the whole system (unless it does because of deadlocks and/or race conditions O:-)) The point is that even if you don't start Kontact, using even the standard systray clock widget will start up akonadi, and with it *all* services that you configured. They may not all be "online", but they're running nonetheless and I have the impression that connectivity issues can bring the system in an "undefined" state. And since all of this middleware stuff happens in the background, without really informing the user that it's there, things like "getting email to work again" can mean having to log off (or even reboot, for really unsavvy users), which is ann
oyingly inelegant in my eyes. Applications relying on middleware, a set of agents sitting between it and the remote service(s) needs an easy way to reset/reinitialise that middleware from within the app itself, if possible with a status ("health") indicator. Having to open a terminal to type something improbable as "akonadictl restart" (or fire up a tool that promptly identifies itself as experimental) is just not acceptable for something so important as a PIM application suite that's the default for a desktop environment targetting a wide audience.
Seriously, akonadi? Ever held a poll to see what things that word evokes or evoked before it became associated with "kmail troubles" and CPU hog?
R.
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users
More information about the kdepim-users
mailing list