Client for SabreDAV: Handling syncs in a single process

64 views
Skip to first unread message

testman

unread,
Apr 27, 2013, 7:02:48 PM4/27/13
to sabredav...@googlegroups.com
Greetings,

I am working on an Android mobile client for a custom installation of SabreDAV.  Due to the nature of the device, where it can frequently be in and out of internet connections, I will have to handle syncing data in a single process.

I will be creating a background service that will work with Android's default calendar.  So on the device, I can keep track of:
  • If the event is "dirty" (this means both if the event has local edits OR if it is new, specifically, it is "unsynced")
  • If the event has been marked for deletion (events will be wiped from the device once I send a delete request to the server)

So in the case where there are local edits, but the ctag hasn't changed for the calendar, I can just push up all of the local edits to the server.  Pulling down server changes with no local edits shouldn't be too bad either.


But since I must handle everything in a single sync process, having both local edits and server edits will be difficult.  My initial idea is for a given calendar, to get all events, both the "local versions" and the "server versions".  From that point, I can handle each event on a case-by-case basis.  Examples:

  • Local event has changes, server has no changes, so update server
  • Local event is marked for deletion, so delete event on server
  • Etag differs, so update local event
  • Event exists on server, not on client, so create on client
  • Event exists on client but has NO CHANGES and NOT MARKED FOR DELETION. Does not exist on server.  So delete on client.

The issue is for the following cases:

  1. Event is "dirty" (it has local changes or was created on the device and not synced), but it doesn't exist on the server.  
    • Either is new event to put on server OR an event that was deleted from the server
  2. Event has both different etag and local changes
    • I will probably just add a SERVER WINS or CLIENT WINS option

There may be more cases.

I have looked at http://code.google.com/p/sabredav/wiki/BuildingACalDAVClient and noticed what Evert said about not being able to sync requests immediately after the client makes a change :P

I am trying to decide if this is something that should be handled by SabreDAV or the client.  For example, possibly somehow getting If-modified-since from the server to handle case 1 above.  Or should I handle this only from the client side?  The issue with this is that I do not believe I have any say on what is inserted into the Android database when an event is created, so I cannot make an additional flag like "new".

Evert Pot

unread,
Apr 29, 2013, 12:08:35 PM4/29/13
to sabredav...@googlegroups.com
Hi!


On Sunday, April 28, 2013 12:02:48 AM UTC+1, testman wrote:
Greetings,

I am working on an Android mobile client for a custom installation of SabreDAV.  Due to the nature of the device, where it can frequently be in and out of internet connections, I will have to handle syncing data in a single process.

I will be creating a background service that will work with Android's default calendar.  So on the device, I can keep track of:
  • If the event is "dirty" (this means both if the event has local edits OR if it is new, specifically, it is "unsynced")
  • If the event has been marked for deletion (events will be wiped from the device once I send a delete request to the server)

So in the case where there are local edits, but the ctag hasn't changed for the calendar, I can just push up all of the local edits to the server.  Pulling down server changes with no local edits shouldn't be too bad either.


But since I must handle everything in a single sync process, having both local edits and server edits will be difficult.  My initial idea is for a given calendar, to get all events, both the "local versions" and the "server versions".  From that point, I can handle each event on a case-by-case basis.  Examples:

  • Local event has changes, server has no changes, so update server
  • Local event is marked for deletion, so delete event on server
  • Etag differs, so update local event
  • Event exists on server, not on client, so create on client
  • Event exists on client but has NO CHANGES and NOT MARKED FOR DELETION. Does not exist on server.  So delete on client.
All these sound solid.

 

The issue is for the following cases:

  1. Event is "dirty" (it has local changes or was created on the device and not synced), but it doesn't exist on the server.  
    • Either is new event to put on server OR an event that was deleted from the server
  2. Event has both different etag and local changes
    • I will probably just add a SERVER WINS or CLIENT WINS option
Generally the rule of thumb with *DAV servers is 'the server always wins'. So if there's a change on both sides (delete, or modification) take the server's version of the truth.

The other option, if you're able to do this is to let the user to the conflict resolution. Some syncing systems do this as well, but most DAV systems just let the server win.

Evert

testman

unread,
May 16, 2013, 7:27:36 PM5/16/13
to sabredav...@googlegroups.com
Evert,

Thank you!
Reply all
Reply to author
Forward
0 new messages