Hi Patrick,
Thanks for the answer. Comments and more questions below.
On 08/29/2011 06:23 PM, Patrick Ohly wrote:
On Mo, 2011-08-29 at 17:22 +0200, Mikel Astiz wrote:
Hi all,
I am trying to synchronize a Nokia phone (6303i Classic) over Bluetooth
with SyncEvolution, and I'm experiencing problems when
"refresh-from-client" is used.
First, are you aware that the phone is the client in that context? So
you are asking for your local data on the desktop to be replaced with
the data on the phone.
Yes, I am aware of this fact.
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?
With the same phone and configuration, it works fine with both "--sync
slow" and "--sync one-way-from-client".
Is there any specific configuration regarding the mode
"refresh-from-client"?
No.
Any ideas on how to debug this issue?
If the output above is all you get, then I can't think of anything.
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.
Either do it before sending the SAN message (has the drawback that the
data is definitely gone, even if the sync never starts), or do it as
part of the initialization in the server after the client has started
the sync. I think SyncContext::getConfigXML() might be a good place. It
already contains some logic for server-initiated syncs, see m_serverMode
and m_remoteInitiated.
I don't know of the top of my head whether the "SyncSource *source"
there was already opened(). If it is, then adding a new method
deleteAllItems() to the SyncSource API would make sense, with a default
implementation that uses the
startDataWrite/readNextItem/deleteItem/endDataWrite Operations.
Yes, I guess it's not a trivial implementation, specially regarding the
transaction failures. I will have a deeper look at the source code
(thanks for the hints) and probably come back to the discussion.
Best regards,
Mikel
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
