On Mon, Jul 21, 2014 at 7:23 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
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 <patrick.ohly@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 1.4.99.3?


sorry for the late reply.
 
I don't care install from source or binary, but I'd like to wait for a relative
stable release, since it's a production server.


--
Emfox Zhou

GnuPG Public Key: 0xF7142EC2