[kdepim-users] KMail SLLLLOOOOOWWWWWW

[Ingo Klöcker]

On Saturday 26 November 2011, Martin Steigerwald wrote:
> Am Donnerstag, 24. November 2011 schrieb Anne Wilson:
> > > and that database is in ~/ which is on a nfs in my case, and
> > > innodb on nfs is a bad idea, and the kde ppl say so themselves,
> > > but still do it.
> > 
> > Yes, there are known problems with nfs home directories. 
> > Apparently it was  not realised how often corporate users have
> > remote home directories, and I expect that making changes to
> > alleviate the problems will not be trivial.

This is FUD. Please stop spreading it. There is no need to make any 
changes to alleviate the problems that exist in the (current) standard 
setup that aims at standalone system users. All you, as corporate user, 
need to change is the setup.


> A topic which I mentioned on this mailing list or pim-ml quite some
> time ago already. And a show stopper for migrating to KMail in our
> company´s environment.

Why? Because the standard setup doesn't suit you out-of-the-box?


> Well it looks like some of the Akonadi design has not been thought
> through to work under all setups.

Which part of the design? The storage location of the database can 
hardly be considered as part of Akonadi's design. So, what part of 
Akonadi's design (as documented at 
http://community.kde.org/KDE_PIM/Akonadi#Architecture) "has not been 
thought through to work under all setups"?

In fact, our decision to use an off-the-shelf database server clearly 
shows that we had requirements in mind that are especially important for 
corporate environments like data integrity, scalability, etc. Obviously, 
we didn't know that MySQL and nfs do not play well together and 
therefore we did probably make a mistake when we decided to use the 
user's home directory instead of something like /var/tmp or /var/cache. 
But still our choice to use a real database to replace our homebrewn, 
errorprone and fragile index files was exactly the right solution.


> As a work-around it might work to tell Akonadi to use /var/tmp or
> whatever for its database. But then its per workstation only which
> has implication when a co-worker works on one workstation and then
> moves to another.

I don't see how this should be a problem if everything is stored on the 
server anyway. Sure, the local cache does not move with the co-worker, 
but that's more or less the definition of a "local cache".


> It can the an advantage, cause different Akonadi
> instances should be able to run at the same time. Or a disadvantage,
> cause there are several databases to be kept up to date.

If you want to avoid this disadvantage then simply use a central 
database for Akonadi. An additional benefit of such a setup is that no 
local mysqld which might eat precious resources needs to run on the 
clients.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20111208/e99d17d5/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users