11:22 a.m.
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. 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
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"? Any ideas on how to debug this issue?
I'm using the latest source tree from the git repository.
Regards,
Mikel
12:23 p.m.
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.
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.
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.
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.
--
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.
4:08 a.m.
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
4:16 a.m.
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.
3473
days inactive
3475
days old
syncevolution@synevolution.org
3 comments
2 participants
participants (2)
-
Mikel Astiz -
Patrick Ohly