Bug 52680

Summary:	Google Contacts + ActiveSync
Product:	SyncEvolution	Reporter:	Patrick Ohly <patrick.ohly>
Component:	SyncEvolution	Assignee:	SyncEvolution Community <syncevolution-issues>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium	CC:	syncevolution-issues
Version:	unspecified
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:	52669
Bug Blocks:

Description Patrick Ohly 2012-07-29 18:36:00 UTC



---- Reported by patrick.ohly@intel.com 2011-10-26 12:43:04 +0000 ----

First test manually, then add to nightly testing. If this works, then it'll be better than accessing Google Contacts via SyncML, because Google's data mapping via SyncML is very incomplete.

Before it can replace the Google SyncML entirely, the GTK UI should better be able to configure ActiveSync.



---- Additional Comments From patrick.ohly@intel.com 2011-11-17 08:15:31 +0000 ----

(In reply to comment #0)
> First test manually, then add to nightly testing. If this works, then it'll be
> better than accessing Google Contacts via SyncML, because Google's data mapping
> via SyncML is very incomplete.

Gave it a try: 	"[SyncEvolution] ActiveSync + Google"

The known limitations in ActiveSync make it impossible to synchronize all data between Evolution and Google. Also ran into 401 errors despite using valid credentials.

My impression is that contact syncing should better be done with a gdata based backend.

> Before it can replace the Google SyncML entirely, the GTK UI should better be
> able to configure ActiveSync.         

That still applies.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 23773 at https://bugs.meego.com/show_bug.cgi?id=23773

Comment 1 Patrick Ohly 2012-08-07 07:42:57 UTC

Another attempt was more successful. Still not perfect, though.

https://syncevolution.org/wiki/google-contacts-activesync

Syncing will try to map all local data to these fields as good as it can. In some cases, for example phone numbers and addresses, this implies throwing away some type information. At the moment, SyncEvolution has no workaround for modified or lost information and will use the updated resp. cleared values when importing an updated contact from Google.

"refresh from local" and uploading many contacts is slow. The slowness is caused by inefficient use of the ActiveSync protocol (each change is a separate request) and will be addressed in future SyncEvolution releases (by batching changes in one request).

While talking to Google via ActiveSync, there is often no visible progress report. For example, a slow sync starts by downloading all contacts. That can take a while without even explaining that this operation is currently happening. Need to add more INFO messages to SyncEvolution.

In the Google web UI, deleted contacts (regardless whether they were deleted during an incremental or refresh sync) are still visible as "other contacts". They can be removed in the web UI.

Because a target config uses state information tied to the activesyncd account config, it is not possible to use multiple sync configurations with the same target. For the same reason, the command line --export operation on a target configuration breaks incremental syncing. Only use it when prepared to do a refresh or slow sync.

Dumping the entire content of the Google address book before and after a sync (dumpData and printChanges properties in the target config) is not possible. There are several reasons: during an incremental sync, the server only sends changes. It can be asked to start over and send all changes, but then the incremental sync no longer works. Requesting individual, unchanged contacts is supported by the ActiveSync protocol and activesyncd, but not implemented by Google.

Comment 2 Patrick Ohly 2013-11-28 16:14:57 UTC

Google discontinued ActiveSync support.

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.