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

[Kumaran Santhanam]

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





--- Comment #74 from Kumaran Santhanam <kumaran alumni stanford org>  2011-01-26 09:47:19 ---
> The cache has two use cases:
> - having often used data accessible locally
> - providing offline capability.

I agree with this requirement.  However, it is a good engineering practice to
have a well-defined flushing policy for any cache.  For example, if there is a
time window that will be cached, then objects outside that window should be
discarded.  What I am uncomfortable with is the fact that the user has no
control over the ever-growing cache files in the home directory.  A good
example is the modern web browser cache which provides the user with sufficient
amount of control over what is saved.

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

As I have posted in the past (i.e. KAddressBook 4.4), I feel that there has
been a lack of user experience analysis on the part of the KDE PIM project. 
Please take a step back and consider the statement above.  Akonadi requires the
user to start an industrial-strength SQL database server just to store email,
contacts, and calendar.  This design decision manifests itself as a tremendous
amount of headache for the end user.  If you search on the Internet for Akonadi
issues, you'll find a large number of users who can't even get the server
started!

I am aware of the ability to use a central MySQL server, or even one on a
different machine.  These are simply not reasonable options for the average
user.  The best approach is to use a file-based (SQLite, BDB, ASCII) backend
that can be easily tested to work on the majority of standard VFS mount points
(local, NFS, AFS, Samba).  My experience in software architecture tells me that
Akonadi is too complex and brittle for the tasks that it is intended to
perform.

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

Akonadi calendar timing was conducted on KDE 4.6 RC2.  KCalDAV timing was
conducted on Kontact 4.4.9.  My general point is that the reasons for the
slow-down are somewhat irrelevant.  The user experience has been compromised to
the point where the new version is not usable in a business environment.

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.