Closed
Bug 797546
Opened 13 years ago
Closed 13 years ago
Send a etag/url only query to check for calendar changes when the number of events is high.
Categories
(Firefox OS Graveyard :: Gaia::Calendar, defect)
Firefox OS Graveyard
Gaia::Calendar
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jlal, Unassigned)
Details
(Whiteboard: [LOE:S])
Background:
When we synchronize calendar events right now we ask for both the etag and the calendar data (full ical string). In some cases that is the right thing (low number of events to sync or initial setup) but otherwise it is likely a waste of the users bandwidth.
Use case:
The assumption is a limited number of events have been added/changed over time and we only want to sync those that have been changed.
First we request the etags of all matching events we know about.
Then we compare events which have etags that do not match the last known value.
For events that do not match we send another query (limited to the changed events) asking for
both the etag (again) and the full ics data.
Steps:
In provider/caldav.js send the list of urls/etags to the caldav worker.
In the worker (service/caldav) request the etags of those events.
Compare with given values, group non-matching etags and make another request with all ical data.
Modify results of stream events to send a value for unchanged events (since we don't have anything to send in this case now).
Support for these steps should exist in our CalDAV client today and should be very simple to implement as the majority of the syncing logic remains the same we simply need to limit the number operations.
| Reporter | ||
Comment 1•13 years ago
|
||
Needs more investigation & work probably good task for v2. We should observe our sync behavior now and see how good/bad the bandwidth usage is.
blocking-basecamp: ? → ---
| Reporter | ||
Comment 2•13 years ago
|
||
We now send the list of etags to the worker an do the comparison there which is the best we are going to do without implementing WebDAV sync (which is not supported by Google/Yahoo). I will open up a separate bug for that.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•