[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