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

[Milian Wolff]

On Monday 29 April 2013 07:30:27 bhlevca wrote:
> Andras Mantia-2 wrote
> 
> > Point out the design problem and than we can talk about something, without
> > it, sorry, this not more, but the usual ranting without supporting
> > evidence
> > of what is the problem...
> 
> Why did I expect a decent answer? I don't know, but this is just another
> rude, mindless email answer defending a bad decision and refusing to see
> that everyone is complaining about KDEPIM.
> 
> If you want a supporting evidence like code lines, you know very well that
> it is very hard to give and would take time. I would rather rewrite the
> whole thing if I had the time.
> 
> But,  If you take the time and cool down as I initially suggested, you will
> notice that in my first message I suggested alternatives (the notmuch mail
> approach) and I pinpointed the culprit: The large behemoth central database
> based design that does everything and is the bottleneck. And I repeat,
> although it is a nice idea, its complexity will bring you down if it didn't
> already.

Considering that I did a bunch of profile runs on kdepim, I rarely, if ever, 
saw a bottleneck in the database. Mysqld is also running just fine.

What we have and what we are working on, is an imported virtuoso/nepomuk 
integration as that is quite often slow. But its getting better and better. 
So: stay tuned and "calm down" as you also say :)

> Last time I tried KDEPIM, although it was better, it was still unusable.
> Try the "notmuch mail" with its blazing fast searches and then compare.

Yes, but that has nothing to do with the "single database" that akonadi uses. 
We actually use two ;-) And the virtuoso/nepomuk one is the slow(er) one, not 
mysql.

> My complaint was a constructive one, it was not a rant as you said and I did
> not want to blame anyone, but to raise awareness that people cannot wait
> forever. I am a programmer myself and I know that complex designs can bring
> down otherwise good ideas. I want KDE to succeed, but I think the akonadi
> based solution was pushed to consumers in pre alpha stage and just harmed
> the project.

Ah, what is constructive and what not lies in the eyes of the beholder. While 
you used more words, its essentially the same as "meh, it doesn't work for me, 
but look - XYZ works for me". While its an interesting hint it won't help much 
if at all. And pointing at the single database is just wrong as that's _not_ 
the problem.

> As other suggested give people a choice to select their backends, even if it
> is a flat file, or a way out.

If someone would write such a second backend and would maintain it... But 
noone is going to do that. Or will you write a backend for notmuch?

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130429/44de92fc/attachment.sig>
-------------- next part --------------
_______________________________________________
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/