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

* Your Email Address
* Spam protection	Enter the letters below: .__ .__..__ __..__. [__)\| \|[__)(__ \| \| \| \|__\|\| \.__)\|__\
Comment	>> 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? >
Attachment
Watch this ticket

Saved Queries