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