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
