[Korganizer-devel] [Bug 133614] add caldav support for sharing calendars

[Kumaran Santhanam]

https://bugs.kde.org/show_bug.cgi?id=133614





--- Comment #72 from Kumaran Santhanam <kumaran alumni stanford org>  2011-01-26 06:52:44 ---
Hi Grégory,

> This sounds counter-intuitive, as it may seem better, performance-wise, to 
> have all the calendar on a local, faster, storage, rather than having to 
> download new entries over the network.

In the previous scheme, the cache is file-based, so searches would be dependent
on the number of entries that were cached.  Since Akonadi uses a relational
database, this may become less of an issue.  However, the purpose of a cache is
to keep frequently used data locally, not create a full mirror of the thousands
of entries on the server.  With this perspective, it seems crufty to cache
thousands of events when they are unlikely to be used.

> I don't get this point: how is the VPN used in this scenario? I guess it's not 
> to download new entries. With you next point in mind I imagine that you may be 
> mounting users home with NFS over the VPN, but that's just a guess.

If somebody adds a new calendar while on VPN, this will become an issue.  Also,
if a force refresh is required for whatever reason, anybody on a slow link will
be waiting for a long time.  Referring to my point above, I feel that it's best
to cache the minimum amount of data necessary to ensure good performance.

> Yup, and Akonadi does not work well in this scenario. To be complete it's the 
> MySQL server that does not deal well with NFS-mounted database files. I can 
> see two points here that may be areas of investigation: using an external 
> MySQL server (meh, not so good over VPN with high-latency / low-bandwidth 
> links); or putting the MySQL database files on another location of the local 
> drive. Spontaneously I think about /var/lib/akonadi-userdata/[user]/, but this 
> has the drawback that moving from one machine to another will need an Akonadi 
> reconfiguration each time… No ideal solution here.

We use NFS-mounted home directories so that a user can seamlessly login to any
equivalent workstation.  This is just on the LAN, not over VPN.

I believe that the use of a full MySQL server for Akonadi was an unfortunate
design decision at the very start.  Since Akonadi become a required component,
it has caused nothing but problems in a wide variety of configurations.  We are
currently forced to symlink the Akonadi directory to
/var/tmp/kdecache-user/akonadi, losing the previous ability to login on any
workstation.  We are working around this limitation by using only KResources so
that the empty Akonadi database can simply be re-created when the user logs in
to a different machine.

These issues are problematic enough that if it gets much worse, we may have to
commit resources to enhance Evolution to the point where we can switch away
from Kontact as our business messaging platform.

> Though it's an interesting problem in itself I don't think that limiting the 
> cached data size provides an interesting solution. If the theft is targeted 
> then having 180 days (as you say later in your message) is ample enough to 
> know the habits of the target, who is he in contact with, etc. One good answer 
> to this problem is full disk encryption, though it's no silver bullet. But 
> this is totally off-topic here :)

This is more of a business perspective.  While 180 days of data may be enough
to surmise a user's habits, the point is that any breaches are limited by
default to 180 days.  Management tends to feel better when they know that the
potential security issues are at least limited to a well-defined time period.

> I can see the problem here. 1.5s is clearly too long. I don't know for sure 
> the internals of Akonadi, so what will follow is an educated guess. Akonadi 
> stores items with many different mime types as opaque data: it does not 
> process the content of events for example an is thus unable to optimize 
> storage based on this content. For events this would be for example the start 
> date / end date, attendees, and so on. Optimization would be to use MySQL 
> indexes to speed up search, and having KOrg issue a special query to get 
> relevant items for the currently selected timeframe, with a little fetch-ahead 
> to be responsive and accomodate users navigating around in their calendars.
>
> This is an interesting problem, and I have no sure idea of how to address it. 
> Maybe KOrg can do the fetch-ahead (and fetch-behind) without special 
> optimization on the MySQL side. Or maybe using Strigi may help searching for 
> items.

I feel that this points to a problem with the Akonadi architecture as a whole. 
The KCalDAV resource is simple and fast.  Akonadi provides no additional
functionality, yet it introduces performance issues.  KOrg should not have to
work around Akonadi limitations.  The Akonadi system needs to be architected
with a good user experience in mind.

> Eh, no problem, I understand :) This bug occured only in one calendar? Have 
> you tested this with others?

Sorry, I wasn't able to test it with others, since I wanted to avoid potential
calendar corruption.

> With this info I think there may have been a conflict in the items that were 
> created. In this case it's the first created one that wins if the second does 
> not properly set the If-None-Match header to match the first item ETag. A HTTP 
> error (4xx) is sent back by the server and caught by the resource, but Akonadi 
> does not display this to the user (at least that was still the case last time 
> I checked), leading you to believe that the item was correctly created while 
> in fact it was not. Looking at the web server logs may help here.

While this explanation may be plausible, please keep in mind that the same
use-cases work correctly with KCalDAV.  Given that Akonadi has not been tested
thoroughly in a business environment, there may be a subtle unresolved issue in
the resource.

Best Regards,
Kumaran

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.