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

[bhlevca]

Hi Kevin,


Kevin Krammer wrote
> Hi Bogdan,
> 
> 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.

No, I still use KDE, but I removed completely any KDEPIM components as they
all need the same akonadi/nepomuk base.
I used kmail and kopete.  Because I cannot use kopete anymore I use a
recently discovered kde product, the  IM contacts (that proves that we can
disconnect some KDE components, though). 
For mail I use claws mail, which does a decent job, but I don't like it as
much as kmail. It still has a one file per mail storage althougk it is not
maildir.


>>  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?

I am sorry that it came that way, I meant that KDEPIM is not as ready for
prime time as the other parts as KDE and it does a disservice to the KDE
platform as a whole. I have seen people who categorized KDE as  junk just
because kdepim was hogging their CPU and IO resources.


>> 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.

Look at this http://xapian.org/ it is used by notmuch and it has the fastest
response time I've seen in a search engine. 
I like the notmuch mail project. Its design philosophy is : simple, lean and
fast.

> If two years down the road it still has problems that means something, and


> 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.

 A simpler approach would have, probably, improved much faster and would be
less KDE bashing online. 


> 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?

I don't have a metric, but as a programmer I know that complex designs are
hard to implement. So that being said, even if the design is good, if it is
too complex it may not be a good way to go. Implementation and maintenance
issues will eat you alive.


> 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?

You have the link to the Xapian API above now


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.
</quote?

True :-)  Akonadi, nepomuk, virtuoso (or another search tool) they all need
some improvement. 

Cheers,
Bogdan




--
View this message in context: http://kde.6490.n7.nabble.com/Akonadi-single-database-design-mistake-tp1053901p1528691.html
Sent from the kde-pim-general mailing list archive at Nabble.com.
_______________________________________________
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/