[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: akonadi

Am Freitag, 26. August 2011 schrieb Ritesh Raj Sarraf:
> Are people here using akonadi or any of the tools using the akonadi
> framework, in their regular workflow?
> (Email, PIM)

I use Akonadi for contacts with KDE 4.6.5 from Debian Sid. This works 
quite nice. I switched the backend to SQLite however, although after 
having switched from a ThinkPad T42 with 2 GiB RAM to a T520 with 8 GiB I 
wouldn´t bother about MySQL anymore and it might even make more sense, 
since threading for database processes then happens within MySQL, not 
akonadi server. And I am not even sure whether it would need that much 
more RAM. It can add up when I run two KDE sessions as I do sometimes.

Completion of mail addresses works a bit differently, now I often have to 
type a complete part of the name with space before it offers any completion 
choice. I find this quite irritating and often thought that it wouldn´t 
work.

Actually everyone without custom packages who uses KAdressBook is using 
Akonadi since Squeeze.

> Also, the same with Nepomuk. Are people using it or is it just sitting
> disabled in everyone's config?

Nepomuk is enabled but I basically do not use it. I disabled Strigi, since 
it crashes on a file it wouldn´t tell me. To what I know a developer 
improved this for KDE 4.7. Nepomuk Strigi in KDE 4.7 uses separate 
processes for indexing. Hopefully its also added that it tells one on 
which file it crashes. And that it skips that file or adds it to a black 
list. Calling DrKonqi for offering writing a bug report would be nice as 
well - cause I consider it a bug when a Strigi analyzer crashes on a file. 
The root bug. Putting Strigi indexers in seperate processes is just a work 
around - that might serve well when the offending file is reported so that I 
can write proper bug reports (and hopefully include the file if its not too 
private).


Actually honestly spoken I am - for KDE 4.6 that is - still quite 
disappointed regarding the state of nepomuk strigi. Its there since ages 
but it never worked for me or even reported on which file it crashed. I do 
think asking the regular user to strace -e file nepomuk strigi processes to 
get down to that information is quite a bit too much to ask. 

I really hope that the maturity of Nepomuk in KDE 4.7 will be better.

I am still reluctant about KMail 2. There have been several data loss 
reports on kdepim-users mailing lists and elsewhere and I have a ton of 
mails still on POP3 account I wouldn´t want to loose.

I am also concerned regarding the performance. I do know that a MySQL 
based mail meta data storage can be blazingly fast - with Zimbra at work 
that opens a +200000 mail folder for linux kernel mailing list as if it 
was nothing. It does so by first listing just the most recent 200-300 mails 
and updating the folder contents as I move the scroll bar.  Also the 
lucene based search index build by the server in background is very fast.

I do hope that KMail 2 can handle at least 35000-40000 mails in one folder 
and can handle 100-200 of folders easily. In a mixed maildir / mbox 
environment. I use mbox for archiving. For that AFAIR it needs some 
performance fixes for mixedmaildir Akonadi resource that are in maildir 
resource already. Well as a work-around I might be able to separate the 
mboxes to a different resource and just use a maildir resource for the 
maildirs.


Actually I wonder whether you Debian Qt/KDE developers are waiting for 
some fixes for almost fully akonadi based KDEPIM to appear before letting 
KDE 4.7 loose to us early adoption users. Maybe you are battling with 
migrating / importing your mail boxes at the moment?


That written, I do think that Akonadi is a great idea. I do also like 
desktop search. I might even find Nepomuk as is useful, as soon as it also 
writes back metadata to files as much as possible, cause I like it to 
remain when copying a directory to a different machine with rsync. I would 
really like if xattrs would be used when the fileformat doesn´t allow for 
meta data.

Its just that these all seem to need quite a bit of maturing. And this 
processes takes quite long already. It seemed to me that KDE developer 
have chosen to tackle enormous tasks and then got overwhelmed by it.

Good news for me is: Since KDE 4.5/4.6 in most other areas and in KDEPIM 
as well KDE developers tend to concentrate on bug fixing. It seems in 
general that KDE 4 finally has landed in some stabilization phase. It needs 
it strongly IMHO. Also good to know is that KDE 5 is not to be intended as 
such a big change-it-all-at-once-(and-see-what-breaks).

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
Reply to: