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

[Kevin Krammer]

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





--- Comment #73 from Kevin Krammer <kevin krammer gmx at>  2011-01-26 09:01:39 ---
(In reply to comment #72)
> 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.

The cache has two use cases:
- having often used data accessible locally
- providing offline capability.

Using a cache timeout results in the first behavior, deactivating the timeout
results in the second one.

Filling of the cache can be done in various ways, e.g. doing an initial full
sync, or just getting a bunch of items and filling the rest later (with
calendars a resource will have to get all items at least once to make sure it
doesn't miss any which could apply to now or the near future due to recurrency
rules).

> 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.

It is important to note that a common misconception about Akonadi's use of
MySQL is that Akonadi requires a per-user instance of mysqld running.

While it is the default option for several reasons, there are quite a number of
other ones, including running a central mysqld instance or on the application
server or using file based SQLite, ...

> > 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.

Following some of the other comments on this report I am not sure which version
of KOrganizer got used for getting the Akonadi calendar timing.
My guess is that it might be the same version used for timing the KResource
based calendar, which obviously would make any numbers for the Akonadi calendar
meaningless (as this would imply using the KResource wrapper plugin which has
to load all calendars synchronously to work around this KOrganizer version's
limitations).

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