CALDAV sync algorithm

Question

I'm trying to implement a syn using caldav and sync reports however I'm having conceptual problems about how to sync one calendar (one VEVENT) between multiple clients and the server.

Most rfc's refer to the use of the etag to determine if a resource has changed since it was last synced. (If the etag changes, the resource has changed since last sync). That I get. However how do I know which change is more recent?

For example client A has an ical 'X' that was last edited at 1AM and they sync at 8AM. Client B also has a version of ical X, that they edited at 2AM and sync at 7AM. So B is newer then A and B synced before A.

When A syncs it will see B's newer version of X. From the etag it knows that X has changed but not 'when'. I'm assuming that A should overwrite with B, since B is newer (or at least be able to prompt the user saying B is newer).... is this assumption correct / is there a standard way to handle this situation?

The problem in general is when trying to figure out what file is newer between the server and a client. The etag only can detect 'changed' but not 'newer'. The last modified date seems to reflect the icals upload date and not its last edit date on the client. This leads me to believe I'm missing something. Is there some generally accepted algorithm for syncing?

Answer 1

The last edit date is just one piece of the equation here. More meaningful is the actual modification. You might have turned off an alarm from device B (insignificant change) but changed the start date from device A (major change). So, a well behaved client should make its best effort at trying to merge the two. Some clients will just notify you that the event had been edited and will ask you which copy to keep but without a side by side comparison UI, this is really confusing for end users. Without a merge mechanism, I would just ignore the etag and always overwrite.

Finally, you should also worry about the schedule-tag of the event (see https://www.rfc-editor.org/rfc/rfc6638#section-3.2.10 ).