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? > > This isn't anything that should be decided based on a user preference. > > The problem is with any backend that allows to retrieve partial data. > Backends like Kolab or WebDAV/ICS load the complete calendar on the > server side anyway, so it doesn't matter speed-wise if we prefetch a > day or a year. Of course it does matter bandwidth-wise. > But the other backends are much quicker loading day views than year > views on the server-side, so prefetching more than what's actually > requested would slow down everything. > > Maybe we could pre-fetch the next (as in later) time range of the > current view, once all calendars have finished loading. This way we > don't slow down the original loading on backends that support > time-range requests, but still speed up the most common navigation > pattern: moving forward. Zooming out to a larger time range would > still have to fill up the missing time slots, but at least that's a > comprise. > >> How is the client cache currently invalidated / how does it know a >> new event was added by someone else? > > Not at all. Kronolith on H6 has a refresh button though. We would > need to track the calendar history, additionally to the event > history, to allow synchronization of calendars to the ajax frontend. >
Attachment
Watch this ticket

Saved Queries