User: Password:
|
|
Subscribe / Log in / New account

Fifteen years of KDE

Fifteen years of KDE

Posted Oct 23, 2011 16:35 UTC (Sun) by anselm (subscriber, #2796)
In reply to: Fifteen years of KDE by krake
Parent article: Fifteen years of KDE

Would kind of also ruin the offline support.

I couldn't care less about KMail's offline support. I run offlineimap, which works a lot better for me, anyway.

[…] but then why remove the caching and offline capability if all you want is to use a different DB engine?

I'd prefer not to have to run a DB engine for the exclusive benefit of my mail program at all, thank you very much. I've been using KMail for years and years without the added complication of a »DB engine«, and I can frankly see no benefit whatever in the added complication. Show me one compelling reason why I would even want to run a complete MySQL or PostgreSQL server just to power my mail reader and I might reconsider. I can tell you right off the bat that caching and offline support are not compelling reasons.


(Log in to post comments)

Fifteen years of KDE

Posted Oct 23, 2011 18:10 UTC (Sun) by krake (subscriber, #55996) [Link]

"I couldn't care less about KMail's offline support. I run offlineimap, which works a lot better for me, anyway."

Fair enough, but I hope you understand that it's not a viable option for everbody. A caching service that can be configured through GUI or does not require any configuration at all is targetted at a different type of user.

Mail clients such as KMail or Thunderbird (and most likely also Evolution) acknowledge that this other type of users exists and thus are capabable of providing caching themselves.

I am confident that there are mail clients which target users such as yourself who can take care of such features externally.

"I've been using KMail for years and years without the added complication of a »DB engine«, and I can frankly see no benefit whatever in the added complication."

Choosing to use software components developed by experts in their respective area is considered a common and recommendable practise, i.e. using established libraries and services instead of implementing everything again (often referred to as as "reinventing the wheel").

A couple of years back a lot of programs used to have their own handcrafted code to deal with relational data, usually using some program specific binary format for data and index files.

Nowadays most of these programs have switched to using existing relational data handling code, usually written by people with a lot more experience in dealing with such data than the end user application developer using the library.

KMail used to be one of the applications that still had its own way of dealing with such data, using its own proprietary index format, etc.
It has just followed the trend to use established and well maintained external code for that. If you need any examples of other software doing that check your package manager's reverse dependencies for libsqlite.

It might look like a weird choice from a user's perspective but a lot of software developers seem to agree that this is a good thing.

"Show me one compelling reason why I would even want to run a complete MySQL or PostgreSQL server just to power my mail reader and I might reconsider."

There is quite a range of possible implementations for relational data handling, the two you are referring to here use a service based approach where engine runs in its own process and clients commmunicate with it.
Other implementation run the engine within the client process, e.g. SQLite.

Depending on factors such as size of data set, access concurrency, support for transactions, etc. some implementations will have different advantages and disadvantages.

Therefore different weighting of these factors will result in different ranking of solutions. If your needs are better matched by an in-process implementation then you should be using one. I don't see any value in trying to persuade you otherwise, after all you know your requirements a lot better than anyone else.

Whether some software you are using is capable of using different implementations is of course dependent on whether its developers anticipated a need to have this kind of customizablity.
In the case of KMail, or more specific Akonadi, this is possible.

Fifteen years of KDE

Posted Oct 23, 2011 22:25 UTC (Sun) by anselm (subscriber, #2796) [Link]

Fair enough, but I hope you understand that it's not a viable option for everbody.

I'm a big believer in Heuer's Law: »Any feature that cannot be turned off is a bug.«

A couple of years back a lot of programs used to have their own handcrafted code to deal with relational data, usually using some program specific binary format for data and index files. Nowadays most of these programs have switched to using existing relational data handling code, usually written by people with a lot more experience in dealing with such data than the end user application developer using the library.

True, but KMail doesn't actually appear to use »relational data«. The Akonadi docs say that in the case of e-mail, everything is stored where it used to be stored (maildirs, IMAP server, …) and cached by Akonadi, except for e-mail flags, which hardly require a relational database infrastructure to store. Hence, in the case of KMail, using something like MySQL appears to be an unnecessary complication. It should be reasonably straightforward to offer the alternative of not caching anything and continuing to use the already-existing code (or something else simple) for e-mail flags in KMail. If I was an Akonadi developer I'd do this just to make debugging easier.

It might look like a weird choice from a user's perspective but a lot of software developers seem to agree that this is a good thing.

This is the logical fallacy known as argumentum ad populum, a.k.a. »if everybody does it, it must be right«. »A lot of software developers seem to agree« that using Java or Windows is a good thing, but even so KDE isn't written in Java for Windows. Go figure.

Whether some software you are using is capable of using different implementations is of course dependent on whether its developers anticipated a need to have this kind of customizablity. In the case of KMail, or more specific Akonadi, this is possible.

According to KDE TechBase, you get to pick your database for Akonadi as long as that database is MySQL. If the Akonadi developers have finally got their act together enough to support a less wasteful storage option then that news does not appear to have made it into the documentation, but then again documentation has never been KDE's strong suit.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds