My thoughts on Slackware, life and everything

Common questions on Akonadi and Nepomuk in KDE PIM 4.8

 I am not usually a copy/paste kind of guy but I thought it is good to have the following information visible on this blog instead of “just” being a forum post.

I was triggered by a linuxquestions.org post which pointed to another post on forum.kde.org called “Common questions on Akonadi and Nepomuk in KDE PIM“. The post contains a Q&A between one of the board admins and Christian Mollenkopf. This is its full text, copied verbatim (and reformatted for this post). I hope this helps some people who wonder why their PC is so busy indexing on every boot.

 

Q&A session with Christian Mollenkopf:

Starting from version 4.7, KDE PIM has integrated Nepomuk for many operations such as search, message tagging, and address auto-completion. This post answers some of the common questions related to the state of this integration.

Q. Will email which is encrypted be indexed in any form, or will it be ignored?
A. It will be ignored since the search index is not secure.

Q. Will the indexer attempt to match the contents of my address book against emails?
A. Yes, the extracted contacts should be merged by email address.

Q. What occurs when email is read or deleted using other clients on shared mail boxes (such as IMAP mail boxes)?
A. It’s either removed or re-indexed.

Q. If the IMAP server supports it, does Akonadi use the server’s search capabilities or index it using Nepomuk anyway?
A. The indexer is protocol agnostic, that is, it works regardless of the server type used, be it POP, IMAP, or local mailbox. If a supported item (a message) is in Akonadi, it’s indexed. If it is changed it’s reindexed, and if it is deleted it’s removed from the index. It doesn’t really matter where the item is coming from.

Q. The performance of mail indexing is slow, how can it be improved?
A. There are different ways to achieve that:

  • Index only what you need. Right click on a folder, select Folder Properties, then the Maintenance tab, then “Disable fulltext indexing“: this will disable indexing for that specific folder;
  • Turn off email indexing altogether by unchecking the relevant option in System Settings, Desktop Search (only available from 4.8 and later);
  • Wait until initial indexing has completed. Indexing is completed when the akonadi_nepomuk_feederrc file in your KDEHOME/share/config directory (KDEHOME is usually .kde or .kde4) contains the following:
    [InitialIndexing]
    IndexCompatLevel=3
  • Locate the akonadi_nepomuk_feederrc file and change DisableIdleDetection to true:
    [akonadi_nepomuk_feeder]
    DisableIdleDetection=true

    This will cause the feeder to keep on indexing regardless of idle status, increasing CPU usage significantly but on the long run reducing the time to complete indexing. As a matter of fact, the real performance issue is the initial indexing, as it can take very long (days with large mailboxes), and is restarted if interrupted (i.e. because of a restart, not by sleep-mode or alike). Once initial indexing is over, performance will be significantly better. The KDE PIM developers are aware of this problem and will work on a solution.

Eric

4 Comments

  1. Helios

    It would also be good to explain how to disable ako nadi and nepomuk.

  2. Nimor

    This might be a dumb question. But can i compile the pim package without the touch programs? Haven’t bothered to check myself 😛

  3. anon

    It would be awesome if stupid hand-holding technologies like this could just be removed completely!

  4. alienbob

    I don’t see how this is a “hand-holding” technology. As I see it, indexing and data-correlation technologies are supposed to stay out of sight and provide you with more meaningful data when you need it.

    Did you actually use akonadi and nepomuk at any time? Do you know what it does?

    Eric

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 Alien Pastures

Theme by Anders NorenUp ↑