[Kde-pim] Akonadi: single database design mistake?

Martin Steigerwald Martin at lichtvoll.de
Thu May 2 11:51:19 BST 2013


Am Mittwoch, 1. Mai 2013, 12:51:42 schrieb ianseeks:
> On Monday 29 Apr 2013 18:42:55 Andras Mantia wrote:
> > ianseeks wrote:
> > > My take on it would be that it should have been a configurable option to
> > > use Akonadi etc or to keep PIM working as it used to
> > 
> > That would require maintainers for the old and new pim applications. Take
> > a
> > look at the number of active pim developers and think about if this would
> > work or not. :)
> 
> I appreciate the number of developers problem and i sympathise.
> My guess is that Akonadi built-in is overkill for most of the users,
> especially non-developers and people who don;t have that much data where a
> few aptly named folders would suffice.  If it ran as a separate service
> that users could have a choice of using, I'm sure life would be easier for
> the PIM developers because they could separate the problems and keep
> concentrating only on PIM issues.

Digikam uses a database.

Amarok uses a database.

Firefox uses several SQLite databases.

Why would Akonadi using a database be so special?


I think KDEPIM-2 is tightly integrated with Akonadi. It would be quite some 
extra work to untangle it again. I think time is better spend in optimizing 
existing backends or if that does not lead to good performance on slower 
laptops than this one, invent a new backend.

Or to put it short: I do think the design ideas behind Akonadi are sound, but 
the current implementation still needs more work.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list