Bug 82872 - CardDAV syncing via PIM Manager API
Summary: CardDAV syncing via PIM Manager API
Status: RESOLVED FIXED
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: PIM Manager (show other bugs)
Version: unspecified
Hardware: Other All
: high enhancement
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-20 15:18 UTC by Patrick Ohly
Modified: 2014-09-24 15:52 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Patrick Ohly 2014-08-20 15:18:12 UTC
It is useful to wrap the CardDAV syncing capability in the PIM Manager API because then a uniform API can be presented to UI developers.

The actual API doesn't have to change, we just need some new fields and a definition what that means for CardDAV. Here's a proposal:

diff --git a/src/dbus/server/pim/README b/src/dbus/server/pim/README
index acb03fa..826df88 100644
--- a/src/dbus/server/pim/README
+++ b/src/dbus/server/pim/README
@@ -292,21 +292,34 @@ Peers
 The following keys are supported for the configuration of a peer:
 
 - "protocol" - defines how to access the address book. "PBAB" (phone
-               book access protocol) and "file" (read vCard files from
-               directory) are implemented. "SyncML" and "CardDAV"
+               book access protocol), "file" (read vCard files from
+               directory) and "CardDAV" (one-way or two way syncing
+               with a CardDAV server) are implemented. "SyncML"
                could be added easily.
 
 - "transport" - defines how to establish the connection. The only
                 supported value is "Bluetooth" (for protocol=PBAP or
                 SyncML), which is also the default if not given
-                explicitly.
+                explicitly. Can be left unset for CardDAV.
 
 - "address" - the Bluetooth MAC address in the aa:bb:cc:dd:ee:ff
-              format (for transport=Bluetooth).
+              format (for transport=Bluetooth); for CardDAV, this can
+              be the name of a SyncEvolution configuration template
+              (for example, "Google") in which case the default
+              address book on that server will be used unless a
+              database is set explicitly
 
 - "database" - empty or unset for the internal address book
                (protocol=PBAP), or the path to the directory
-               (protocol=file).
+               (protocol=file), or the URL of a specific contact
+               collection (protocol=CardDAV, overrides the "address")
+
+- "syncmode" - "cache" for one-way syncing with local read-only data (the only
+               allowed value for protocol=PBAP and the default if unset),
+               "two-way" for two-way syncing with locally writable data.
+               In two-way mode, SyncEvolution minimizes user interaction
+               when resolving problems (no slow sync prevention, for
+               example).
 
 - "logdir" - a directory in which directories are created with debug
              information about sync session.
@@ -322,6 +335,7 @@ The following keys are supported for the configuration of a peer:
 Not supported via the API at the moment:
 - selecting a specific phone address book
 - selecting which vCard properties get cached
+- listing all available CardDAV contact collections
 
 Syncing
 =======
@@ -688,6 +702,14 @@ If matching fails, a contact will get deleted and recreated. The end result
 in the unified address book is still the same, because folks does not
 rely on the ID for linking.
 
+With CardDAV, only the initial sync downloads all contacts. Any
+following sync uses locally stored meta data about the server to
+detect changes (added, updated, deleted contacts) and then applies
+these changes locally. If an incremental sync is impossible for
+whatever reason (for example, the local meta data about the CardDAV
+server got lost), SyncEvolution falls back to the PBAP approach of
+comparing local and remote data and updating the local side.
+
 Supported fields
 ----------------
Comment 1 Mateusz Polrola 2014-08-22 08:06:20 UTC
Seems fine for me.
Just from curiosity - it possible that CardDAV will also support incremental sync ? (I'm not sure if this will be as much usable as in case of PBAP)
Comment 2 Patrick Ohly 2014-08-22 08:21:08 UTC
(In reply to comment #1)
> Seems fine for me.
> Just from curiosity - it possible that CardDAV will also support incremental
> sync ? (I'm not sure if this will be as much usable as in case of PBAP)

Note that "incremental" is a bit misleading when used outside of the PBAP context. Traditionally, "incremental sync" means "retrieve only changes and apply them". CardDAV supports that.

It doesn't support downloading without PHOTOs and adding them later. There was no need for it because current servers have no efficient way of getting contacts without their PHOTO data.

You mentioned elsewhere that iCloud seems to refer to PHOTOs via URLs. In that case, such a mode would make sense.
Comment 3 Patrick Ohly 2014-08-27 13:55:35 UTC
"username", "password" are also needed.

One more thing to watch out for is disk writes when nothing changed. During a normal sync, SyncEvolution updates the "nonce" string on both sides and some date strings. The amount of modified data is small and typically the file sizes don't change. However, the .ini files get written anew and then renamed, so the amount of written data is larger than just the changes. I think the .bfi files are updated in place, but I need to check.

$ diff -r /home/pohly/.config/syncevolution/pim-manager-google/  pim-manager-google/ | diffstat
 /.internal.ini                                                                           |    2 +-
 pim-manager-google/peers/eds/.@pim-manager-google/.synthesis/remote_1_clg_sysynclib_.bfi |binary
 pim-manager-google/peers/eds/.@pim-manager-google/.synthesis/sysynclib_prof.bfi          |binary
 pim-manager-google/peers/eds/.@pim-manager-google/.synthesis/sysynclib_targ.bfi          |binary
 pim-manager-google/peers/eds/.internal.ini                                               |    4 ++--
 pim-manager-google/peers/eds/sources/local/.internal.ini                                 |    2 +-
 6 files changed, 4 insertions(+), 4 deletions(-)

-rw-r--r-- 1 pohly pallas   44 Aug 27 15:03 .internal.ini
-rw-r--r-- 1 pohly pallas  801 Aug 27 15:39 peers/eds/.internal.ini
-rw-r--r-- 1 pohly pallas 4520 Aug 27 15:39 peers/eds/.@pim-manager-google/.synthesis/remote_1_clg_sysynclib_.bfi
-rw-r--r-- 1 pohly pallas 1780 Aug 27 15:39 peers/eds/.@pim-manager-google/.synthesis/sysynclib_prof.bfi
-rw-r--r-- 1 pohly pallas 1524 Aug 27 15:39 peers/eds/.@pim-manager-google/.synthesis/sysynclib_targ.bfi
-rw-r--r-- 1 pohly pallas  471 Aug 27 15:39 peers/eds/sources/local/.internal.ini

It might be possible to treat the case of "nothing changed" as special and finish the sync without updating these files.
Comment 4 Patrick Ohly 2014-09-24 15:52:17 UTC
Included in 1.4.99.4.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.