Confirmed users
503
edits
Calendar Talk:Feature Implementations:Calendar Cache: Difference between revisions
Jump to navigation
Jump to search
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 |
||
| Line 29: | Line 29: | ||
the entire file, queries can be done on the local copy. (this is currently | 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) | 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 | |||