KMail2 doesn't store information in databases

Posted Nov 24, 2011 14:47 UTC (Thu) by wstephenson (guest, #14795)
In reply to: KMail2 doesn't store information in databases by anselm
Parent article: Trinity Desktop Environment: Keeping KDE 3 alive

Possible but undesirable. An email client that has to parse an entire mbox or maildir or go out to the IMAP server every time you enter a folder would only be useful for trivial amounts of mail. Even pine and mutt have email header and addressbook caches, and those are provided by 3rd party database libraries. When you consider KDE's Akonadi is not just tightly coupled to KMail or even email, having a standalone server process to allow PIM data to be accessed from the mailer, the clock calendar popup, the biff replacement, or the IM client, with the minimum amount of unshared state eating up your RAM begins to look like a good idea.

KMail2 doesn't store information in databases

Posted Nov 24, 2011 15:01 UTC (Thu) by anselm (subscriber, #2796) [Link] (5 responses)

Funnily enough, I don't see a big performance difference between the KMail of KDE 3.5 and that of KDE 4.x. (Actually, I'd expect my KDE 4.x KMail to be quite a bit faster than my KDE 3.5 KMail because it is running on a much beefier machine. Something must be eating up the difference, I wonder what that might be )

KMail2 doesn't store information in databases

Posted Nov 25, 2011 21:49 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (4 responses)

KMail1 had its own internal database, KMail2 re-uses MySQL. I guess MySQL, which is after all a more generic database, is not as fast as the internal database of KMail1 was.

There are probably also still quite some opportunities for performance improvements since much of this is new while KMail1 had been optimized for years.

But essentially, there is no difference in KMail1 and KMail2 except that the backend of KMail1 is abstracted out and uses MySQL (or other backends, they are plugins after all) instead of a home-brewn solution.

Sounds like an improvement to me. I am very much aware that currently, it doesn't feel like that with the stability and esp performance issues and all, but a change for the good often consists of one step backwards, two steps forwards.

KMail2 doesn't store information in databases

Posted Nov 26, 2011 11:44 UTC (Sat) by wazoox (subscriber, #69624) [Link] (3 responses)

Question: using MySQL as a desktop application backend strikes me as unnecessarily heavy; what did bring people NOT to use some variation of Berkeley DB, or one of many DBM implementations (dbm, Tokyo Cabinet, HamsterDB, etc)?

KMail2 doesn't store information in databases

Posted Nov 27, 2011 10:12 UTC (Sun) by wstephenson (guest, #14795) [Link] (2 responses)

Akonadi uses the QtSql api, which supports database plugins. MySQL is the default; sqlite and Postgres are options. We found that the heavily multiprocess and -threaded approach used on desktop builds ran into threading problems with sqlite. For the embedded/mobile builds where some components are run in-process for a smaller footprint, sqlite is used. Postgres support just needs more work and optimisation as has been done for MySQL, to reduce its footprint to the bare minimum needed. I'm not sure why BDB wasn't chosen.

KMail2 doesn't store information in databases

Posted Nov 28, 2011 9:10 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

Presumably because BDB doesn't support SQL directly. You could try implementing an SQL engine on top of BDB but you would just be reinventing SQLite, which is essentially an SQL engine on top of BDB.

KMail2 doesn't store information in databases

Posted Nov 28, 2011 13:39 UTC (Mon) by nix (subscriber, #2304) [Link]

What? There's no BDB involved in SQLite. It uses fairly conventional database data structures to store data, not a key/value hash.