On Thu, 2014-07-17 at 08:26 +0200, Patrick Ohly 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,
> syncing was stopped by server every 35 or 47 contacts or so, I
> 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".
I implemented addressbook-multiget support. It's currently undergoing
automated testing before being merged into the master branch:
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Jul 18 16:19:40 2014 +0200
CardDAV: implement read-ahead
Instead of downloading contacts one-by-one with GET, SyncEvolution now
looks at contacts that are most likely going to be needed soon and
gets all of them at once with addressbook-multiget REPORT.
The number of contacts per REPORT is 50 by default, configurable by
setting the SYNCEVOLUTION_CARDDAV_BATCH_SIZE env variable.
This has two advantages:
- It avoids round-trips to the server and thus speeds up a large
download (100 small contacts with individual GETs took 28s on
a fast connection, 3s with two REPORTs).
- It reduces the overall number of requests. Google CardDAV is known
to start issuing intermittent 401 authentication errors when the
number of contacts retrieved via GET is too large. Perhaps this
can be avoided with addressbook-multiget.
This is similar to read-ahead in EDS contacts. However, because we
cannot run Neon requests asynchronously (at least not easily), a
batched read must complete before any contact from it can be
returned to the caller.
Emfox, do you think you could compile from source to give this a try,
or, once it is ready, use 184.108.40.206?
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.