Calendar Talk:Feature Implementations:Calendar Cache

offline (so not caching!)

Have one remote file. Have one local mirror of that file. Store all changes in the local mirror and in a changelist file. When online, sync.

syncing means: Download remote file. Play changelist on it. For every change, make sure the remote item is the item the change was applied to. When done, upload file, replace local mirror with new file, remove changelist. If the old item in the changelist doesn't match the item on the remote file, there was a conflict. This needs to be handled in a nice way. (Ask the user?)

changelist:

• item-id
• old item (or null, for addition)
• new item (or null, for deletion)

If an item was changed twice, only one item is needed. The new change item overwrites the old.

Assumes there is a file to be downloaded. Providers need a flag indicating they can do this. If there is no real file (like wcap, caldav), they could download into a storage calendar. It should still work when only part of the remote calendar is downloaded, because the local storage is not used for anything except showing items when offline.

There is some caching possible with this: When a provider supports downloading the entire file, queries can be done on the local copy. (this is currently already how ics calendar work, with a memory provider as local copy)

The big question: how and where should this be implemented? Inside the providers means that code can not be shared. In a wrapper means a mess when creating the calendars. In an utility class, to be called by the providers?

Noting that from all this, the only thing an always-cache provider has to do is download the remote items, upload them and maybe some locking. It does have to parse the items into a local provider (likely storage). Queries will be forwarded. And this is what ics already does. Difference is that ics manages the local provider, instead of letting the wrapper or utility do that