Looking for input from Kontact users

[ITSEF Admin]

On Thursday 15 December 2011 11:38:15 Alvin wrote:
> On Thursday 08 December 2011 15:58:37 ITSEF Admin wrote:
> > [...]
> > - What version of Kontact are you using (e35, "the one that came with the
> > distribution", ...)?
>
> Kontact 4.7.4 (The one that comes with Kubuntu 11.10 + PPA)

Right, that's the one we're running a one-user pilot with right now.


> > - On which platform and with how many users?
>
> Only myself. For testing. Other users in the company are using our older
> mail server with Kontact, Thunderbird or Outlook. Only for mail. Kontact
> users have the version that came with Kubuntu 10.04, but are requesting a
> change to Thunderbird due to stability issues.

That is consistent with what we saw - Kontact is far from being stable... :-(

[...]
> > - What are your experiences with Kontact with regard to
> >   * stability (crashes...)
> >   * reliability (lost mail, lost appointments, ....)
> >   * overall "good behaviour"
>
> - When sending mail, plasma often crashes.
> - Some mails can't be marked as read.
> - Loading a message can take several minutes. I just clicked a plain text
> message that is already downloaded. The preview pane says "Retrieving
> Folder Contents" Please wait... In a few minutes, I'll be able to read the
> mail. - Checking an DIMAP folder for the first time after startup of
> Kontact often takes a long time.

Yes, we've seen those as well at times, but with e35 on Kubuntu 10.04. So far, 
the KDE4/Kubuntu 11.10 version seems to fate a little bit better.


> - Nepomuk/virtuoso eats my memory. It's better now, but the first time I
> received mail from the server the machine needed 2 days and nights to calm
> down.

That is one of my concerns as well. This could be seen on both our pilot 
machine and on my machine at home where I was experimenting with Kontact as 
well.


> - I no longer use the "Find Messages". The load on the system is just too
> high.

That has been the case with Kontact as long as we've been using it - one of 
the most frequent complaints of our users.

[... rest of list with flakey behaviour skipped ...]

> So, not very 'production ready'. It's a shame. KMail has every function I
> have come to expect from a mail client. I loved KMail in KDE3 and I find
> Akonadi a fantastic idea. If only it weren's so buggy. Increase the
> performance, take out the bugs and you have a gem.

Hmpf, that all sounds not very confidence inspiring... Akonadi seems to be the 
one element to start with that is apparently far from production ready - 
there is a whole list of potential issues that make me wonder whether we 
should even consider seriously trying it:
- Akonadi doesn't start up on NFS-mounted home directories unless a workaround 
is applied - that's an (K)Ubuntu/AppArmomr problem 
(https://bugs.launchpad.net/ubuntu/+source/akonadi/+bug/913589)
- Akonadi is fragile on NFS-mounted home directories: KDE bug 275261, 
https://bugs.kde.org/show_bug.cgi?id=275261)
- Akonadi seems to be limited to stand-alone single-user machines by initial 
design - at least that's the impression I get when I look at the following 
excerpt from KDE's own "Deployment Issues" list 
(http://techbase.kde.org/Projects/PIM/Akonadi#Deployment_issues):
    * Multiple access: Should multiple Akonadi instances' mysqlds access a 
single set of data files the mysql will likely corrupt the data. This can 
happen in any NFS+YP installation where users can log onto any machine and 
access shared homes. MySQL relies on filesystem locking to prevent multiple 
access. ["MySQL multiple instance docu" given as reference, Oracle has moved 
everything around - should be this: 
http://docs.oracle.com/cd/E19957-01/mysql-refman-6.0/server-administration.html]
    * InnoDB tables should not be used on NFS. [Again, Oracle had moved 
things - seems to be linked to this: 
http://docs.oracle.com/cd/E19957-01/mysql-refman-6.0/storage-engines.html#innodb-restrictions]
    * NFS speed: MySQL documentation recommends against locating its data 
files on network shares.
[...]
    * Backup: MySQL data files should not be backed up without telling the 
mysqld process, otherwise a corrupt backup will be made. LOCK TABLES and 
FLUSH TABLES at the least. A dump can be made or mysqlhotbackup may be used 
in some circumstances. We should consider sysadmins' backup techniques when 
planning/promoting Akonadi, as a simple rsync cronjob with running Akonadi 
will not work. MySQL backup advice. [this point does not matter much to us, 
fortunately, but I see it as a severe restriction, as it makes backup more 
difficult]

More than enough to cast doubt on whether newer Kontact versions using Akonadi 
are a good idea when used in a multi-user, NFS-based environment. At the very 
least, we'd probably have to investigate whether it is possible to use a 
central MySQL server for Akonadi - the idea of every user having to run 
his/her own MySQL-server instance seems somewhat crazy to me...
Nonetheless, if anybody out there has some additional insight, I'd be much 
obliged.

Cheerio,

Thomas

P.S. (as it is rather OT on this list):
> We're in the process of evaluating a new mail server for the company. I use
> Kolab personally, but for the company, Kolab was ruled out due to
> difficulty of installation/upgrade and missing documentation. Also, most
> people are using a recent version of Thunderbird now.

Maybe you'd like to share (off-list) what you're looking at right now?
-- 
------------------------------------------------------------------------------
           Thomas Ribbrock, IT-Team brightsight