Is there any way at all to not run Akonadi? Not now, not ever?

Thanks
Philippe

KDE will be introducing further dependence, especially in the PIM area, on Akonadi in KDE 4.5 and following releases. This is not likely to be reverted.

Is there any particular reason you wish to "get rid of" akonadi? At least on my ( KDE Trunk ) system, it stays out of my way (not a single message on startup), although it is started up automatically by the Plasma clock.

I was afraid of that. My immediate problem with Akonadi is that I can't seem to get it working with KAddressBook. In trying to making it work, I have now lost the connection to the address book data. std.vcf is still there but I can't reconfigure Akonadi or KAddressBook to read it. It seems ridiculous that there are three different places where the data source for KAddressBook can be configured, none of which is working for me at the present time.

On a deeper level though, I am just not convinced that the whole idea is worth it for me. Akonadi needs Nepomuk and Nepomuk needs Strigi and I have no use for either. I am not at all convinced that we need a single API to access data as disparate as addresses, email, calendar, notes and what have you. It also bothers me that we need to install two separate, heavy duty DBMS where none was needed before, and I'm already running PostgreSQL. Last but not least, I have a backup system based on rsync/unison and it's not clear to me that this will work with those DBMS.

To make things even less tempting, I get goose bumps every time I read somewhere about the « teething problems » of Akonadi. In general, I don't mind these sorts of problems. As long as I have alternatives, and as long as I don't loose any functionality. In this case, I had problems with distribution lists, and now no address book at all.

So, in summary, I don't like Akonadi, I don't want it, but it seems I don't have a choice. So I am very unhappy. Perhaps the time has come to move all that stuff to Google mail and be done with it.

Sorry about the rant.
Philippe

i agree with pclerie. For my needs, Akonadi is like a solution looking for a problem.

I've drop Kmail in favor of Thunderbird, deactivate Nepomuk and start KDE with "akonadictl stop".

ultima.ratio wrote:I've drop Kmail in favor of Thunderbird, deactivate Nepomuk and start KDE with "akonadictl stop".

Thanks, ratio. I switched to Thunderbird and just put up with the error messages.

A couple of people on other forums tell me akonadi works properly on Gnome. I hope so because Gnome is going down the same path. Kaddressbook hasn't worked properly on any of my systems for the last year, or so.

pclerie wrote:Is there any way at all to not run Akonadi? Not now, not ever?

Thanks
Philippe

I asked that question last year, when I gave up on thinking Akonadi errors might be a configuration issue. There are a few messages on the Arch and Ubuntu forums suggesting they've solved the Akonadi issue with clever configuration work arounds. None of those work arounds did anything here, not even on clean installs.

Switching to Gnome isn't the answer, either. Gnome is also committed to using it. I find Gnome feels somewhat anemic compared to KDE but they don't seem to have the Akonadi errors that everyone I know had with KDE. Eventually, I'll follow my co-workers to Gnome but I'm hoping the KDE team can get it going before I feel forced to do that.

I recommend switching to Thunderbird and then using ultima.ratio's command to kill it on startup or you could just ignore the errors like I've been doing. You'll have to get away from Kontact if you want to get away from Akonadi.

1. So, essentially, one of the complaints here is that 'you need another heavy-duty database'. And that is something that is worse than having every application implement its own database, indexing and searching mechanisms (like it was before, and like it is with tbird and most other programs)?

2. Nepomuk doesn't need strigi. It never did. And, that is something that was talked about in at least 5 different threads on this forum.

Ivan,

I am aware that Strigi is not an absolute requirement, if you are not concerned about speed for Nepomuk. Since I don't intend to use Nepomuk I can activate it for Akonadi without Strigi. On the other hand the official documentation does recommend Strigi.

As for the databases, my understanding of Akonadi is that Mysql is _not_ used for holding the applications' data. It stores metadata, and I have no idea at all what that metadata is. So the applications still use the same old files (or databases if you prefer). Any data stored in Mysql databases is _additional_. It's entirely possible I got that part wrong, so feel free to correct me.

And yes I would prefer that each application use their own database. Then I can switch apps whenever and wherever I want provided of course that the data is in a standard format usable by other apps. That's not the case with Akonadi.


tomb17, ultima.ratio

Thanks for the suggestions. However, I will switch to Thunderbird if and when they use the maildir format. Last time I checked (couple of years ago) they were not. I've got a couple of horror stories about the mbox format I do not want to repeat.

Cheers
Philippe

"I am aware that Strigi is not an absolute requirement"

Ok, not to beat around the bush - it is not a requirement at all, in any sense of the word.

"As for the databases, my understanding of Akonadi is that Mysql is _not_ used for holding the applications' data"

It holds the data like 'from/to', 'subject' and similar for faster searches.

"So the applications still use the same old files (or databases if you prefer)."

These two are different - 'old files' and 'databases'. Most apps work like this - you have the files in some standard format (mbox, ...), then you have index files which are not usually standardized and are used for faster searching.

Now, what akonadi does (one of the things) is that it replaces those custom index files and custom search code with one of the fastest free/libre databases - mysql.

Thus, you have an optimized code that is shared between all apps. Less memory and less CPU power.

"And yes I would prefer that each application use their own database. Then I can switch apps whenever and wherever I want provided of course that the data is in a standard format usable by other apps. That's not the case with Akonadi."

See the previous paragraph.

Let me make sure we are on the same wavelength here. First, I am not saying Akonadi is bad or useless. I am saying that I feel I (me, myself) don't need it. The way I use those apps do not require the advanced technology Akonadi is proposing therefore I would have liked the option to stay with what I am already comfortable with.

Look at it this way: I only have ~200 contacts. My calendar has <500 entries. No journals. I have ~100 entries in kjots. Then ~40,000 assorted emails in various folders, the largest of which has 10,000 entries. The next largest has ~5,000. On a modern computer, the speed gain from mysql indexes is at best marginal in terms of perception. 95% of the searches I do don't even require the Find function. When I do use Find I get the answer I need within 10-20 sec and that's good enough for me.

All this stuff dates back from 2004. If I want more speed I can clean up. Which I should do anyway. There was something on the net last week about the dangers of not forgetting and some of my past postings are downright embarrassing.

I have no doubt that Akonadi is a fine piece of technology. But in my case, it feels like using a bazooka to kill a fly.

Hope that clears up my position.

Cheers
Philippe

Ok, I understand your point of view, and I agree that you'll not benefit that much from Akonadi compared to what you had in old PIM.

----
A side-note about indexes:

The indexes are not used only for (explicit) searching:
- when showing a list of mails, index is used to get the subjects, dates etc. The alternative would be to reread all mail files every time you open a folder with messages which would be *very* slow.
- when opening a specific message, index contains its location (file name or something). The alternative would be to keep the filenames in memory (or, even worse, the whole messages) which would take a lot more memory.

This applies not only to Akonadi, but other programs as well - the only difference here is that akonadi is a system that is shared by all PIM apps.

Indexes are like cache, try disabling CPU cache via BIOS and see how much speed you'll lose.
----

Unfortunately, we (speaking as a general KDE dev, I'm not in KDEPIM) are not able to tailor KDE SC to each person separately.

(for example) Some would like to rate things from 1-5, some from 1-10, I'd like 0-10... some don't want rating at all. I guess that for 99.9% of features in every program (not only KDE SC), there will be a user that doesn't use it.

So, we have to make our software cover most (sane) use-cases for most people.

@Ivan,

Indexes are useful for a certain amount of data. For some of us, it's like arguing that QuickSort is far better than BublbeSort for a list of less than 10 items.

Maybe there is a need for a lightweight KDE and a full featured KDE. (i know, it's easier to say ...)

Anyway, thanks to KDE devs for their work.

ultima.ratio wrote:Maybe there is a need for a lightweight KDE and a full featured KDE. (i know, it's easier to say ...)

That would be totally cool, if the lightweight KDE had everything the full featured KDE has with the exception of Akonadi.

ultima.ratio wrote:@Ivan,

Indexes are useful for a certain amount of data. For some of us, it's like arguing that QuickSort is far better than BublbeSort for a list of less than 10 items.

Ok, if you consider your 40k mails to me that small in number

ultima.ratio wrote:Maybe there is a need for a lightweight KDE and a full featured KDE. (i know, it's easier to say ...)

We are not against this idea, but it is not very likely to happen soon - no enough man-power. If somebody would be willing to maintain something like this, I don't think the other devs would say no.

Since there there have been a couple of points spread over several postings, I am not replying to any of them specifically.

Databases:

Akonadi is designed to support basically any SQL capable data base that fullfills the basic requirements, e.g. multithreading capability, transactions.

Currently known to work are MySQL and PostgreSQL, both as separate instances and as shared instances (i.e. system service).
SQLite had problems until quite recently so I am not sure if this also works repliably already.

Using the database engine also used by Nepomuk, Virtuoso, would of course be nice, but its driver is not up to the task yet on the SQL side of things (its RDF driver seems to be very good).

What kind of data is stored in the database depends a bit on the data types and on the setup.

One thing that is stored for internal purposes is metadata like what revision an item has, which MIME type the data is of, where it came from, which collection it is in and so on.
Relational data is what relation databases have been designed for so the are very efficient there.

Then there is potentially application specific metadata, so called attributes. E.g. when a mail composer creates a mail item to be sent, it can use attributes to attach information like which account it should be sent with or where the mail should be moved to after sending.

Depending on the configuration and data sizes, real data can be in the database as well.
The main purpose of Akonadi as a service (akonadiserver process) is to provide caching.
E.g. headers of emails for fast listing of email folders, full mails for IMAP folders that need to accessible offline.

Up to a certain size this data might also be in the database, over the threshold it is put into cache files.

As for not starting Akonadi: Akonadi is, as of now, a service which is started on demand by applications using it.
At some point it might make sense to launch it at session login, e.g. to not have to start any application just to check for new mails.

Cheers,
_