Confirmed users
503
edits
Calendar Talk:Feature Implementations:Calendar Cache: Difference between revisions
Calendar Talk:Feature Implementations:Calendar Cache (view source)
Revision as of 13:53, 30 December 2006
, 30 December 2006no edit summary
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
offline (so not caching!) | offline (so not caching!) | ||
| Line 24: | Line 22: | ||
can do this. If there is no real file (like wcap, caldav), they could download | 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 | into a storage calendar. It should still work when only part of the remote | ||
calendar is downloaded, because the local | 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 | |||