1:58 p.m.
On Thu, 2014-07-17 at 15:06 +0800, Emfox Zhou wrote:
On Thu, Jul 17, 2014 at 2:26 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
On Thu, 2014-07-17 at 00:38 +0800, Emfox Zhou wrote:
> Not that more, my main account has more than 900 contacts,
and others
> has less the 20. I started to sync new contacts into another
account,
> the
> syncing was stopped by server every 35 or 47 contacts or so,
I
> restarted
> the process several times, and when the contacts reached
190, the same
> error of my main google account appeared.
>
>
> What a pity, does this mean I should dispose my old phone
into
> trash? ...
No, it just means that you need to use OAuth2 (with the
current
SyncEvolution version) or until someone (me?) finds the time
to add a
read-ahead buffer based on CARDDAV:addressbook-multiget
instead of the
current "one GET per contact".
What is your distro on the desktop and on the server where you
run
SyncEvolution?
How to use OAuth2?
See the 1.4 release notes for a summary and pointers:
https://syncevolution.org/blogs/pohly/2014/syncevolution-14-released
My server is running on Debian wheezy/stable, which is now many
package
are upgraded to unstable.
The problem is that OAuth expects an interactive login via a web
browser. If you can update to gnome-control-center 3.8 (from Unstable or
Testing) on your server *and* run it from remote (ssh -X), then you can
log into your account and then use username=goa;<email address> without
password in SyncEvolution to access the Google CardDAV server.
However, I had problems running gnome-control-center in a VNC session (X
forwarding wasn't an (easy) option for me), apparently because it was
expecting more X capabilities that provided by the VNC server. Your
mileage may vary. My fallback solution was to log into Google on my
desktop, then copy GNOME keyring entries and GOA configs to the remote
test machine.
You don't need to have X running when using OAuth in SyncEvolution.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.