(In reply to comment #0)
> I've got a samsung nexus with android 4.3 with a few contacts (just for
> testing). The phone is paired over bluetooth with my laptop. I did an
> initial sync with those commands:
> 
> syncevolution --configure \
>                 syncURL= \
>                 addressbook/backend=pbap \
>                 addressbook/database=obex-bt://$mac_addr \
>                 target-config@pbap addressbook
> 
> syncevolution --configure \
>                 --template SyncEvolution_Client \
> 		--keyring=no \
>                 syncURL=local://@pbap \
>                 pbap
> 
> syncevolution --sync refresh-from-client pbap addressbook
> 
> This imports all contacts perfectly.
>
> Then on the android phone I edit a
> contact and add an email address, and run that command on laptop to sync:
> 
> syncevolution pbap addressbook
> 
> And it says there are no changes.

What is the exact output? Which sync mode were you using?

With the commands above, it should attempt a two-way sync. That mode does not work with PBAP, because the protocol and thus source are read-only.

The expected outcome is that a slow sync should be enforced, which by default is not executed unless the user consents. I just tried, and I got (as expected):


+---------------|-----------------------|-----------------------|-CON-+
|               |       @default        |       @default        | FLI |
|        Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|    galaxy-eds |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
|    unexpected slow sync (local, status 22000)                       |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          start Tue Mar 25 15:42:00 2014, duration 0:02min           |
|             unexpected slow sync (local, status 22000)              |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: local, status 20048

Doing a slow synchronization may lead to duplicated items or
lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
    slow, refresh-from-server, refresh-from-client

The message has not been updated to cover read-only sources and/or the new "caching" mode. It should detect that the remote pbap source cannot do incremental syncing and therefore suggest refresh-from-remote or local-cache-incremental.

Using "--sync local-cache preventslowsync=0" worked for me here. That preventslowsync=0 has to be specified explicitly is a bit unexpected. It should be implied automatically by local-cache or local-cache-incremental. I'll fix that.

Obviously this PBAP caching feature has not been polished for "normal" users. I did not expect someone to be interested in using it.

Ping? Is this still a problem?

Sorry, I've been working on other stuff lately, will try to come back at this later and investigate more in details what our platform does/needs.

I'll pick this up. In setting up a development environment with syncevolution 1.4 I'm getting an error when I try the initial pbap setup like this:

I have an android device paired with the bluetooth dongle, and run the following:

syncevolution --configure \
                syncURL= \
                addressbook/backend=pbap \
		addressbook/database=obex-bt://XX:XX:XX:XX:XX:XX \
                preventSlowSync=false \
                target-config@pbap addressbook

http://pastebin.com/5ephg2EZ

Do I need some other library in order for addressbook/backend=pbap to be recognized?

To enable the PBAP backend, one has to compile from source with --enable-pbap as part of the configure invocation.

Patrick,

"Using "--sync local-cache preventslowsync=0" worked for me here. That preventslowsync=0 has to be specified explicitly is a bit unexpected. It should be implied automatically by local-cache or local-cache-incremental. I'll fix that."

Did this get fixed? If so I'll test with a newer release than what I had previously checked. If not I'll just suggest adding this option to our client.

preventslowsync still has to be set explicitly. I am waiting for the result of your investigations before making changes.

Another inconsistency regarding preventSlowSync (from the README.rst):

   **Warning:** because the client in the local sync starts the sync,
   ``preventSlowSync=0`` must be set in the target config to have an effect.
 
This is inconsistent. Should we allow the user to set preventSlowSync
in the originating config and use that on the target side?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/42.