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
@@ -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. 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), 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
- "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
@@ -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.
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)
(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.
"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/.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.
Included in 18.104.22.168.