Summary: | Add an option to compile Akregator without Akonadi | ||
---|---|---|---|
Product: | [Applications] akregator | Reporter: | Woodsman <darrella> |
Component: | akonadi-port | Assignee: | Frank Osterfeld <osterfeld> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | kamikazow |
Priority: | NOR | ||
Version: | 4.10.1 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Other | ||
Latest Commit: | Version Fixed In: |
Description
Woodsman
2013-03-29 23:57:03 UTC
Akregator never used KResources but its own storage backend interface. Maintaining both that and an Akonadi version in the same code base isn't really feasible - the code uses Akonadi::Item and Akonadi::Collection directly, and I don't see another abstraction layer justified. Not to mention that the current backend has severe issues: It causes crashes regularly, huge memory consumption and large startup times when having many items. Thanks for replying and explaining. :) I'm not a large scale user and I never see crashes or buggy behavior, although I do understand. My hope is for small scale users who enjoy KDE that somehow Akonadi can be disabled or neutralized. I appreciate what Akonadi can do for certain types of users, but small scale users are not part of that group. I fear the result is such users will abandon kdepim altogether. I'm in that group. I don't use Akonadi but I have used KMail, KAlarm, and Akregator for a long time. When the Akregator Akonadi changes are merged into trunk I'll have to find alternatives, much like the other PIM apps. That makes me sad. Thanks for a nice app through the years. :) (In reply to Frank Osterfeld from comment #1) > Akregator never used KResources but its own storage backend interface. > Maintaining both that and an Akonadi version in the same code base isn't > really feasible So, WONTFIX, right? |