[Tickets #13279] Re: Improve caching of events in daily / weekly view

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13279
------------------------------------------------------------------------------
  Ticket             | 13279
  Updated By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | Improve caching of events in daily / weekly view
  Queue              | Kronolith
  Version            | Git master
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2014-06-23 08:12) wrote:

> Are you talking about client-side or server-side caching? We only  
> cache Kolab data server-side, the client-side cache is independent  
> from the backend and doesn't persist sessions.
> Of course "zooming in" to calendar views is quicker than zooming out  
> or navigation forth or back. Pre-fetching doesn't make much sense,  
> because you might fetch data which you will never use resp. display,  
> and there is typical navigation pattern like in IMP that we could  
> use to predict that data we might need next.

yes, client side caching is probably what I had in mind.
I guess you mean there is *no* typical pattern like in imp.

Let me give you an example:
Changing the current day view in our company wide calendar takes about  
three to four seconds (using a Kolab backend). Kronolith starts up  
with the current work week if you enter it for the first time.

When I change to the year view first, it takes about four seconds to  
load the calendar for the whole year. Now I change back to the week  
view. It only takes one second to flip through different weeks now.

The Kolab backend is not every efficient when it needs to load only  
parts of a calendar.
Even if we add an index to the event data, it still does a lot of  
backend hits as it checks for new shares (IMAP folders) and so on.  
That results in four IMAP logins on the server.

May be we can build some kind of optional prefetch that can be  
disabled by a pref?

How is the client cache currently invalidated / how does it know a new  
event was added by someone else?