On Fri, 2016-11-11 at 20:11 +0100, deloptes wrote:
Patrick Ohly wrote:
> Perhaps that's the reason for the if() check: a HTTP server might
> require a different LocURI (?) than an OBEX server, and the code does
> not immediately know what it is (depends on the transport).
I don't see it in the sync via bluetooth. I see in the html log
device ID: syncevolution-33702b00-09b0-4a05-8eb0-4057b41667a6
device ID: syncevolution-5c646a89-d7bb-4338-b5b5-3e6f4eb6e1f9
Where do you see that?
In the xml I see only the Nokia/Phone ID
I was also thinking that based on the device ID it might be deciding to
compare all items, which perhaps makes also sense. I'm not sure.
The initial, so called SAN message, is not getting dumped. See
SyncContext::sendSAN() for the code which generates it. That there's no
LocURI for SyncEvolution confirms my theory that the phone can't
distinguish between the different computers.
However, after thinking some more about it I suspect that sending a
LocURI as part of the SyncML session wouldn't help: basically the phone
picks the configuration (and thus the sync anchors) based on the
information in the SAN message. At least that's how SyncEvolution does
It's worth trying with remoteIdentifier set differently on the two
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.