KMail dependence on Akonadi

[Duncan]

Leslie Turriff posted on Fri, 07 Jul 2017 23:01:57 -0500 as excerpted:

> On 2017-07-07 18:37:22 Aleksey Midenkov wrote:
>> By what purpose there is KMail dependence on other services? Can it
>> work standalone?
> 
> Based on the responses that I saw during the rollout of KDE4 and the
> confusion that Akonadi caused, the KDE developers think that Akonadi is
> a wonderful tool that should be connected to every other component of
> KDE, whether or not that makes sense, and regardless of any adverse
> impacts that it causes.  I believe that eventually the community was
> able to convince them to put in some sort of mechanism for disabling
> Akonadi, but I'm not sure that doing so does not in some ways cripple
> the parts of KDE (e.g. Kmail) that depend on it.  Akonadi is one of the
> major new "features" that have caused me to retain KDE3 as my desktop.

You may be confusing akonadi and nepomuk/baloo.

FWIW, akonadi is a database-backend specific to kdepim and its component 
applications.  It's what now handles contact information such as email 
addresses, IRC handles, phone numbers, IM addresses, etc, and by now it's 
a mandatory dependency of pretty much anything kdepim related.

*BUT*, the dependency is limited to kdepim.

*HOWEVER*, kmail is a kdepim component, so, unfortunately, requires 
akonadi.

In theory, akonadi is a kdepim shared service, and the kdepim developers 
like it because individual apps don't have to write all the contact 
handling code for each app, they simply write to the akonadi interface 
and let it take care of the rest of the backend.

And in theory, users should like it for two reasons: One, because they 
devs don't have to write and rewrite the functionality for multiple apps, 
they should have more time to do other "nice things", bugfix or implement 
fancy new features that they'd not have time to do if they were spending 
it maintaining their individual contact information code.  Two, with the 
shared backend, a single contact can be entered once, and it will appear 
in all the various kdepim apps, kmail, the irc client, the IM client, 
etc, with a reasonably common and thus familiar GUI, learn the contact 
management GUI once and you should know it for the entire kdepim family 
of apps.

Unfortunately, akonadi as a database backend data handler has been 
demonstrated to be rather less than stable for many users, to crash 
frequently, and to rather frustratingly lose data, messages, etc.  Often, 
the appropriate database-rebuild incantation can bring them back, but...

In my case, some time ago I asked myself why I was putting up with it.  
Email isn't rocket science, tho it has been around since rocket 
scientists were walking on the moon, and by now it's stable technology 
with time-proven techniques for managing it without crashing, without 
losing messages, and while staying relatively fast.

After asking myself that I realized there wasn't a good answer, so soon 
enough I WASN'T putting up with it, and had switched to a much more 
stable email app.

In my case I chose claws-mail, replacing both kmail and akregator (the 
kdepim-based feed-reader) with it, and I've been very happy.  But I've 
known others that went with Thunderbird or Evolution.  (Those weren't 
good choices for me for several reasons, including that they use 
databases too, altho their database usage seems to be more stable, 
evolution being a gnome client and bringing in way more gnome deps than I 
wanted, and both of them being HTML-based mail clients, while I prefer a 
mail client that doesn't do HTML by default, for security reasons.)

That's akonadi, limited to kdepim but mandatory there, the reason I don't 
have anything kdepim related on my system, any longer.

Nepomuk/baloo, meanwhile, is a general purpose file-indexer, of course 
with its own database storing the results so they're instantly 
available.  Baloo is the current incarnation, replacing the nepomuk from 
early kde4 in late kde4.

So this is entirely different.  Baloo is /not/ mandatory for most of kde, 
tho it is for a few small componenents, but the option to support it or 
not is normally a build-time option, choosing to link in the library for 
that support, or not, and most binary distros enable it by default, 
making it mandatory for their kde packages as they're normally linked 
against it and thus won't run without it.

It's possible there's a few "kde-lite" binary distros that disable baloo 
at build time, but meanwhile, even if it's enabled at build-time and 
installation is thus mandatory, it can be turned off, tho a few functions 
it provides then become unavailable.

For source-based distros such as gentoo, meanwhile, baloo can be an 
option, as it is for gentoo's kde/plasma, controlled by the semantic-
desktop USE flag.  FWIW I'm a gentooer, and I have the option disabled 
here, so my kde/plasma is built without baloo, and my system doesn't have 
it installed at all.  Because I built without baloo in the first place, 
things still run even if it's not installed, tho again I'm missing a few 
bits of functionality it would enable.

But for me those bits of functionality aren't worth the hassle of 
constantly fighting with a file indexer that will either be trying to 
update its database at an inconvenient time, or won't have the data I 
need anyway, because its index is outdated.  Besides, the database tends 
to be several gigs of data, and I deliberately keep a relatively small 
/home partition, because I keep media and similar things elsewhere, so 
pretty much all /home has on it is the user config, and it doesn't NEED 
to be too big... unless of course I'm running baloo, and storing gigs of 
data that I can grep or otherwise look up in any case...

So I find I'm better off without akonadi or baloo, but have ensured that 
happened in different ways as appropriate for each.  For akonadi, I 
simply switched off of any kdepim-based applications (including kmail) 
that would require it if I still had them installed, so don't need 
akonadi.  For the more general usage file indexer baloo, and the semantic-
desktop in general, I simply turn the option off at build time, which I 
can do with just a toggle of a USE flag before build and install since 
I'm using gentoo. =:^)

But for those running binary distros that build against and thus require 
baloo be installed, at least it can be turned off at runtime and the apps 
that use it will for the most part still work.  Unlike akonadi, which 
while limited to kdepim apps, is absolutely required for them to 
function, so the only way to disable it is to choose something other than 
a kdepim based application.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman