+1
FWIW, I had started working towards this a looong time ago, but other 
projects took my time. I'd still like to eventually get this 
implemented when I have the time...

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

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?

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.

Hi,

one user reported a funny behaviour: When you have a calendar with 
lots of events (say 5.000+),
clicking through the daily / weekly view has a considerable delay - at 
least using a Kolab backend.

If you enter kronolith through the yearly view / switch once to the 
yearly view,
it's blazing fast even in the daily view.

-> So the yearly view builds up some cache that's re-used for the daily view.

It would be nice to build up this cache in the daily view, too.
One strategy would be to cache the events for the whole month of the 
current day.
Or current day +- 30 days.

That would make pagination in the daily view a lot faster.

Tested with the Kolab backend, but I can imagine the (client side?) cache
also avoids backend hits for the SQL backend.

Opinions?