Re: Kmail and Akonadi

On Sunday, 2012-03-25, John Aldrich wrote:

> *sigh* I REALY wish the developers would stop adding new features and
> settle the system down.

I am actually not sure if any of the KDEPIM core developers currently invest 
any significant time in new features. Any features in particular you're 
thinking about?

> I still don't understand why an email client NEEDS
> a database!

That answer is easy but rather difficult to explain.
An email client does not need a database but it is a sensible choice to use 
one.

Bascially when creating an software a number of parts need to come together, a 
number of smaller problems need to be solved.

Since the example used here is email clients, standard problems include things 
like email parsing and generation (MIME message structures can be arbitrarily 
complex), access to email storage (either local or on servers), potentially 
sending mail (through calling a local helper or SMTP), rendering of emails 
(plain text, HTML, etc) and so on.

For each single problem there are always two possible approaches: creating 
your own solution or using an existing solution.
The latter obviously only applicable when such a thing exists.

Both approaches have their advantages and disadvanteges.
The advantages for the first being control (schedules, feature set) and 
tailoring (feature set, programming model, etc). The disadvantages of course 
being more initial work and, even more importantly, maintenance costs.

The advantages of the second approach being little inital work, offloaded or 
shared maintenance and usually also the work being done by specialists in the 
respective field. The disadvantages in turn being having to rely on others, 
dealing with too much or too less generic interfaces, etc.

A good example for the first approach is usually email parsing, i.e. basically 
all email clients in existance have their own library for taking a raw email 
and making sense of it. The main reason is probably that no generic enough 
solutions exists, i.e. all existing implementations have been tailored (see 
advantages) to the needs of a particular client or framework, making it hard 
to impossible to be used elsewhere.

An example for the second approach, at least in GUI email clients, is usually 
visualization. Common UI frameworks like Qt or GTK+ are being used for the 
client's chrome, email rendering is often offloaded to one of only a few HTML 
rendering engines (KHTML or successors like WebKit, Gecko).

One other area of functionality is handling of associated data or meta data, 
subdivided into storage of said meta data and storing/quering the relation 
between the meta data and the respective emails.

Depending on the actual email storage facility, some or all of that can be 
stored with the email data, e.g. maildir allows to store certain state 
information (read/unread) by approriately formatting email file names, others 
like mbox don't.

As we have seen above, the question ultimately boils down to "do it yourself" 
vs. "depend on something else".

KMail1 is an example of an email client following approach number one, it had 
custom binary (for access speed reasons) index files stored either with the 
mails (locally stored emails) or in a shadow folder structure (remotely stored 
emails).

Most other clients approach this by understanding that the problem is more 
widely known as relational data, which has multiple existing solutions (called 
relational databases) implemented, mantained and improved by specialists of 
their field (see advantages).

Mozilla Thinderbird, GNOME Evolution, KDE Kontact Email (a.k.a. KMail2) are 
examples of that approach.

So, as I wrote in the introduction, not a question of need to have but not an 
unreasonable thing to have.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iD8DBQBPb0BpnKMhG6pzZJIRAm9eAJ9bmanxZK6kdbPMu/JH4wG0uYokOwCfUa5K
qV0RvVd0GweCuDkddFV6mEo=
=aZdB
-----END PGP SIGNATURE-----