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 > > <Source> > <LocURI>IMEI:xxxxxxxxxxxxxxxx/LocURI> > </Source> > .... > <Source> > <LocURI>./devinf12</LocURI> > </Source> > .... > <Source> > <LocURI>./contacts</LocURI> > </Source> > > 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. It's worth trying with remoteIdentifier set differently on the two computers. -- 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
