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

[Kevin Krammer]

Hi Bogdan,

On Monday, 2013-04-29, bhlevca wrote:
> 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.

Ah, I see, thanks for clarifying!

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

Yeah, I wonder how any mail client can still not use single files per message 
storage. KMail had switched to maildir like a decade ago.  Never understood 
why Thunderbird didn't switch as well.

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

Ah, you meant part of the Software Compilation release. This will probably go 
away anyway, way to many people not understanding the concept of product 
bundles.

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

Definitely interesting. Maybe we are lucky and somebody will find time to 
evaluate whether it provides the necessary feature set.

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

Maybe, but people are bashing all sorts of thing they have no idea about. For 
example they are not only bashing Nepomuk based search but also Akonadi based 
data access.

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

Very true. 
However, sometimes you need a certain complexity to solve the tasks at hand. 
Just ignoring the complicated tasks might make solutions simplier but also 
limited. This becomes then mostly a matter of weighting advantages against 
disadvantages.

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

Right. Though that only addresses the search part. This thread originally 
started as a discussion of PIM data access so I mixed that up.
As I said above, it would be interesting to see if it can provide the search 
needs alonside the data access mechanism provided by Akonadi.

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/b2ef32f3/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/