Ok I will look into the eTags and make sure they are only changing when there is actually a change. However the issue for us is the database calls because our CalDav server is mapping data from our own data source into an ICS format it means that every update is hitting our databases retrieving the data (even if it just a subset) and then creating the uri/etag. This puts a fair bit of load on our server to be constantly request the same data regularly. Our calendars may have many hundreds (or even 1000’s) of entries. This means it does this data call every time.
I don’t know your server design, but please note that CalDAV and CardDAV servers MUST support ETags (https://tools.ietf.org/html/rfc4791#section-5.3.4 and https://tools.ietf.org/html/rfc6352#section-18.104.22.168). ETags are the method to determine whether a resource has changed.
CalDAV: It’s exclusive with REPORT calendar-query which allows to get only events filtered by a certain time span. This will be a feature that comes next. And the server can either tell DAVdroid all events from 2015/01/01 to 2016/01/01 (for example), or what has changed since the last sync.
This may solve the problem - certainly filtering the time span requested is very useful. However the last sync is similar to the what I’m requesting, and may do the job as well perhaps?
Yes, the “what has changed since last sync” method would be the “WebDav Collection Sync” method requested by you. However, it operates on WebDAV level (not CalDAV/CardDAV), so I’d really prefer to use time span filtering instead.
Is their a limit to the amount of contacts stored in Android - I hadn’t thought of that before as a possible issue - we were looking at giving some users an address book of their customers - which could be many 1000’s of people.
As far as I’m aware of, there’s no theoretical limit and thousands should theoretically be sync-able without problems. The limit is the amount of memory and performance of the sync algorithms.
Thank-you for taking the time to expand on this. I can understand for use cases where the information is fairly static or of low numbers but the use cases I’m looking at involve shared data with a high numbers of contacts and events that will change on a regular basis.
I see. But just to note: If data changes regularly and it shall be synchronized, there will of course be traffic to transmit these data, regardless of which method is used.