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

[Grégory Oestreicher]

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





--- Comment #70 from Grégory Oestreicher <greg kamago net>  2011-01-23 09:24:08 ---
Hi Kumaran,

> > Are you talking about the resource performance here?
> 
> There is probably a mix of resource and KOrganizer issues. 

There are even three actors in this play: Akonadi, the resource and KOrg. The 
resource is mostly just a simple worker that will download the calendar 
entries and that will discover new calendars.

> However, I do
> think that as a baseline improvement, the resource should not cache the
> entire calendar. 

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.

> We came across this some time back during KCalDAV
> development. Currently, we have DAViCal server with nearly a dozen
> calendars and thousands of simple and complex events.  Caching the entire
> calendar presents the following problems:
> 
> 1) Very slow performance over remote VPN links.

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.

> 2) Extra server overhead for NFS-mounted home directories.

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.

> 3) Security concerns in the case of a lost or stolen laptop.

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 :)

> From a user experience perspective, the primary test is how fast the
> calendar can be paged week-by-week.  Simply set the calendar to "Week"
> view and repeatedly click the right arrow to page to subsequent weeks. 
> For one calendar with over 500 events, my tests showed that KCalDAV
> renders the next week in about 250ms, while the Akonadi version takes over
> 1.5s.  This is a common use case for business users, since people often
> look for availability in the next few weeks when scheduling meetings.

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.

[Items not created / synced]

> Unfortunately, I don't have a repeatable sequence of steps to recreate the
> problem.  I had a similar intermittent bug a while back in KCalDAV and was
> only able to resolve it by carefully reading the code and finding an error
> in the XML construction. 

Events creation is rather straightforward and does not involve XML: it's just 
using an HTTP PUT request (via KIO::storedPut) with the item payload as the 
request body and the appropriate If-None-Match HTTP header.

> I also would not be able to provide access to
> the calendar which exhibited this problem, since it is internal to the
> company. 

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

> My best suggestion would be to create a large calendar (1000+
> events, with recurrences and all-day events) and read/write simultaneously
> from multiple clients. Perhaps you can read the code and spot something
> that might be causing the issue.

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.

Cheers,
Grégory

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