On Mi, 2011-08-31 at 10:08 +0200, Mikel Astiz wrote: > On 08/29/2011 06:23 PM, Patrick Ohly wrote: > > On Mo, 2011-08-29 at 17:22 +0200, Mikel Astiz wrote: > >> The synchronization process starts but > >> then stalls indefinitely until timeouted or manually cancelled. > >> > >> The output I get is the following: > >> obex_parse_connect_header(): requested MTU=32767, used MTU=32767 > >> [INFO] Server sending SAN > >> obex_data_request(): len = 104 bytes > >> fdobex_write(): sending 104 bytes > >> obex_data_indication(): Got 0 bytes msg len=3 > >> obex_data_request(): len = 40 bytes > >> fdobex_write(): sending 40 bytes > >> obex_data_indication(): Got 1005 bytes msg len=1008 > >> obex_data_indication(): Got 971 bytes msg len=1979 > >> obex_data_request(): len = 4821 bytes > >> fdobex_write(): sending 4821 bytes > >> obex_data_indication(): Got 0 bytes msg len=3 > >> obex_data_request(): len = 40 bytes > >> fdobex_write(): sending 40 bytes > > I suspect that the phone simply doesn't support this mode of operation. > > Any suggestions on how to confirm this hypothesis? If so, does that mean > that the operation should fail?
A properly behaving phone should shut down the connection (thus rejecting the server initiated sync) or start the sync as requested. This phone does neither, which definitely isn't correct. > > There may be a workaround: delete all local data, then ask for a slow > > sync. That could even be implemented as default in SyncEvolution when > > the server initiates the sync. > > Does sounds like a server-side emulation of the "refresh-from-client". > To me it makes sense as a fallback mode of operation, if the client does > not support it. But as we cannot determine whether the client supports it, IMHO it makes sense to do it like that by default. -- 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] http://lists.syncevolution.org/listinfo/syncevolution
