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

[Kevin Krammer]

Hi Bogdan,

On Saturday, 2013-04-27, bhlevca wrote:
> Hi,
> 
> Before you throw any flames at me please note that I am a KDE fan and I am
> using it everywhere on my computers.
> 
> I almost dumped KDE for LXDE and XFCE ( I hate gnome) about 2 years ago
> when I switched to kmail2 and the whole akonadi/nepomuk/virtuoso.  It was
> way too slow to buggy and unusable. I was losing data that I could not
> afford to lose.
> I hung on it for a couple of months like any harcore KDE fan, but in the
> end it was too much to take.

I am not sure I understand this fully. So KMail was the only KDE software you 
had been using and you discontinued to do so after the switch to KMail2.
So far so good, but I don't think neither LXDE nor XFCE have a mail client you 
could have switched to.

One possible but not likely interpretation is that you also stopped using the 
KDE workspace product Plasma Desktop and started using the workspace product 
of LXDE or XFCE instead.
As I said, a very unlikely interpretation since those two products are 
independent, so it would be great if you could clarify that point.

>  KDE is awesome and it becomes more usable by the day, but honestly kdepim
> should not be a part of it.

KDE is a very welcoming community, why should the people working on PIM 
applications not be part of it?

> If you guys want an example of blazing fast search look at "notmuch". I use
> it through emacs as my second email platform and is the fastest email
> search I have. Dump the crappy system you use now and focus on something
> that works fast and that's not the monolithic mysql based solution.

Out search provider doesn't use MySQL, it is using Virtuoso.
It was chosen out of the available options at that point as the one with best 
potential. Naturally that doesn't have to be the case all the time, maybe 
there is now a better option.

> If two years down the road it still has problems that means something, and
> that something is a design problem.

Not necessarily. Even a perfect design can have an imperfect implementation. 
The fact that the implementation continually improves would suggest that the 
design is actually quite good to begin with and the implementation is catching 
up.
By which metric did you arrive at the conclusion that the implementation is as 
good as it can be and that the problem is at the design level?

> Calm down and go to the design board
> and look at what works or not. I stongly suggest a solution similar to what
> http://notmuchmail.org/  did.  It can be used for contacts and other PIM
> features, not email only.

I had a quick look and I couldn't find any API documentation.
Can you quickly elaborate how it provides a unified way of access across all 
currently used PIM data types and how it ensures extensibility for new ones?

Or did you mean alongside Akonadi for the actual data access needs?
The thread was initially about Akonadi but it seems to have moved into the 
search area at some place.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20130429/720a1a7a/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/