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, > > 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".
I implemented addressbook-multiget support. It's currently undergoing automated testing before being merged into the master branch: commit 0c989eb74d870b5800ac69a25bb97402f37d6a62 Author: Patrick Ohly <[email protected]> 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 1.4.99.3? -- 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
