Why cache rewrite ?

The current cache suffers from the following issues,

• String parsing eats cpu everytime the calendar is queried.
• Forms a huge xml file with all the calendar items causing slowness in the write operations.
• Hard to store calendar items as ECalComponent objects as EFileCache expects objects to be strings.
• Not abstracted well enough to inherit and write an alternate one (eg: a db based one) if we need in future.
• Not threadsafe (not a requirement for a new cache, but we have a old patch waiting for a long time)

New Cache

So considering these, I am considering to write a new cache and have a name ECalBackendStore so that it is not confusing with the existing one. The design is as simple as,

The new cache is going to be like the internal cache in file backend keeping all the components as ECalComponent's in memory. The calendar events will be stored in .ics file format. There will be another file keys.xml to store the custom keys which backends would need.

The reason we have chosen to keep the components in memory is, calendars will not have huge data like mailer component and so a database might not be needed. But if someone wants to implement a db, the new design will allow them to do the same without affecting the providers. The current assumption made is having all the calendar contents in memory will not be costly considering ammount of data people usually have.

I am looking at the GSoc patches as well to have them merged along with this.

The virtual functions in the new cache will almost be the same as the old one. We will be providing an api to migrate from the old xml cache to the new file based one.

Affected backends

All backends except file and exchange use ECalBackendCache. We need to migrate them to the new one once its completed. The migration effort needed would be a day as I foresee now. I will be able to provide what exactly needs to be done once the new cache is done.