Does Davdroid support WebDav Sync?



  • We have configured our own CalDav Server using SabreDav.
    When we connect via an Apple IOS device the client will make use of WebDav Sync to get only the latest changes so it doesn't require a full update of data.

    See http://sabre.io/dav/sync/

    However I notice that Davdroid does not use this feature which means every update it gets a lot of data. Is this something that Davdroid does or will support?

    If this has been mentioned before sorry I couldn't find any reference to it (or my google-fu sucks)

    Andrew


  • developer

    Hi, thanks for your suggestion :)

    @starfishmod said:

    However I notice that Davdroid does not use this feature which means every update it gets a lot of data.

    1. DAVdroid supports CTags.
    2. Even if the CTag of a collection changes, only the file names and ETags of all collection members will be transferred.
    3. Regarding the content of members: only those with changed ETag will be transferred.

    Can you please given more information about how much data is transferred and why you think this is a problem? Especially if you're talking about CalDAV, CardDAV or both and some details for both cases. I'd like to know hard facts (how much traffic can be saved etc.) so that we can estimate the usefulness.

    Is this something that Davdroid does or will support?

    I don't know why some people call it "WebDAV Sync" – this doesn't make any sense for me. WebDAV synchronization is synchronization with WebDAV. What RFC 6578 describes and what we're talking about is "Collection Synchronization for WebDAV", but we can call it "WebDAV Collection Sync" too.

    Does DAVdroid support it? No¹ . I don't know it if makes much sense:

    1. 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.
    2. CardDAV: Would make more sense here (because there's no filtering), but we're still looking at the possibilities of REPORT addressbook-query. Also, normally you don't have as many contacts as events, so I don't know if it would be worth the efforts.

    Basically, WebDAV Collection Sync seems to be a WebDAV (= file synchronization) feature for me which has only limited value for CalDAV/CardDAV clients (but may of course has its use cases).

    ¹ With our new framework and libraries, it would be possible to support it.



  • Thanks for writing a in-depth response

    @rfc2822 said:

    1. DAVdroid supports CTags.
    2. Even if the CTag of a collection changes, only the file names and ETags of all collection members will be transferred.
    3. Regarding the content of members: only those with changed ETag will be transferred.

    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.

    Where as IOS says (after the initial sync) what has changed. 90% of the time nothing has changed and it therefore sends no data and the database is under a far reduced load.

    Can you please given more information about how much data is transferred and why you think this is a problem? Especially if you're talking about CalDAV, CardDAV or both and some details for both cases. I'd like to know hard facts (how much traffic can be saved etc.) so that we can estimate the usefulness.

    Yes I will try to do some stats next week on dav data transfered using dav droid vs ios.

    Is this something that Davdroid does or will support?

    I don't know why some people call it "WebDAV Sync" – this doesn't make any sense for me. WebDAV synchronization is synchronization with WebDAV. What RFC 6578 describes and what we're talking about is "Collection Synchronization for WebDAV", but we can call it "WebDAV Collection Sync" too.

    I'm fairly new to a lot of this so I'm just getting my head around a lot of the nomenclature :)

    Does DAVdroid support it? No¹ . I don't know it if makes much sense:

    1. 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?
    1. CardDAV: Would make more sense here (because there's no filtering), but we're still looking at the possibilities of REPORT addressbook-query. Also, normally you don't have as many contacts as events, so I don't know if it would be worth the efforts.

    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.

    Basically, WebDAV Collection Sync seems to be a WebDAV (= file synchronization) feature for me which has only limited value for CalDAV/CardDAV clients (but may of course has its use cases).
    ¹ With our new framework and libraries, it would be possible to support it.

    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.

    Andrew


  • developer

    @starfishmod said:

    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-6.3.2.3). ETags are the method to determine whether a resource has changed.

    1. 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.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.