289
edits
Calendar:Cache: Difference between revisions
no edit summary
No edit summary |
|||
| Line 83: | Line 83: | ||
This observer also fills the cache calendar on initial setup. In the future a better way for caldav can be implemented, where the storage calendar has added knowledge about the auth calendar, and can query it. | This observer also fills the cache calendar on initial setup. In the future a better way for caldav can be implemented, where the storage calendar has added knowledge about the auth calendar, and can query it. | ||
==Notes from Toronto meeting discussion== | |||
caching calendar/offline calendar/device sync | |||
history: | |||
mvl/dmose came up with basic design for using storage calendar to hold | |||
offline calendars | |||
already implemented by wcap. could be genericized so it could be used | |||
for all calendars | |||
change to ui -> | |||
ui writes to local storage calendar and writes changelog -> | |||
changelog used to push changes to non-local providers (ics, wcap, etc.) | |||
in the case of connectivity loss, changelog can be played back when | |||
connectivity returns. (implies sync mechanism) | |||
who wins in the case of conflicts? | |||
could create an ics from the cache so we can use 3rd party sync stuff | |||
- scaling issues? | |||
- caldir helps for fs sharing | |||
1. calICaching | |||
2. syncing from offline changes | |||
3. ics backend? and device sync storing | |||
4. file locking | |||
How SimDesk dealt with conflicts | |||
Type Server Local Action | |||
1 Update Update merge dialog | |||
2 Update Delete server wins (cause it got updated) | |||
3 Delete Update dialog | |||
4 Delete Delete | |||
5 Insert Insert | |||