Hi Patrick,
Just changing getSyncStateAlertCode() call with the second argument set to
false does the same trick. Because that second parameter switches between
"simplified" (true) and "standard conformant" (false) client alert codes
already.
uInt16 alertCode = getSyncStateAlertCode(fServerAlerted,true);
Just because support for refresh-from sync modes was so bad in the early SyncML
days, this parameter remained a constant.
> The "true" part needs to be replaced with a configuration option that
> chooses between old (use "slow sync") and new behavior (use "refresh
> from server").
That now applies to that second parameter of getSyncStateAlertCode()
> Or has enough time passed that we no longer have to care
> about servers which implement slow sync, but not refresh from server?
The benefit of SyncML in general and libsynthesis in particular is that it
works with real legacy systems. In fact, the more time passes, the more the
main reason for using libsynthesis will become smooth legacy support. So I
wouldn't want to switch standard behaviour here, and opt for a config flag.
Best Regards,
Lukas
On 06.06.2012, at 15:49, Patrick Ohly wrote:
> Hello!
>
> It seems that Funambol has implemented some kind of protection against
> excessive slow syncs: I can do a slow sync once fine. Doing it again
> shortly afterwards (say, a few seconds later, as in automated testing)
> results in a 417 "retry later" status for the Alert command (in the
> SyncML response message).
>
> They have not responded to my question about this behavior, so I don't
> have an official confirmation that my interpretation is correct.
>
> This server behavior makes one (otherwise useful) feature of
> libsynthesis a bit troublesome: when an app requests a refresh from
> server ("forceslow" = 1, "syncmode" = 1 in the binfile client API), then
> the engine will ask the server for a slow sync instead of telling it to
> do a refresh-from-server. In other words, the Funambol server has to
> assume the worst (a slow sync) and applies its throttling even though
> the client only wants to do a relatively benign "refresh from server".
>
> I've checked that the Funambol server does many "refresh from server"
> syncs without 417. For that I patched libsynthesis:
>
> diff --git a/src/sysync/localengineds.cpp b/src/sysync/localengineds.cpp
> index ce3d034..98f15dc 100644
> --- a/src/sysync/localengineds.cpp
> +++ b/src/sysync/localengineds.cpp
> @@ -3481,6 +3481,11 @@ localstatus TLocalEngineDS::engGenerateClientSyncAlert(
> ));
> // create appropriate initial alert command
> uInt16 alertCode = getSyncStateAlertCode(fServerAlerted,true);
> + if (alertCode == 201 &&
> + fSyncMode == smo_fromserver &&
> + true) {
> + alertCode = 205;
> + }
> // check for resume
> if (fResuming) {
> // check if what we resume is same as what we wanted to do
>
> Does that patch look right in principle?
>
> The "true" part needs to be replaced with a configuration option that
> chooses between old (use "slow sync") and new behavior (use "refresh
> from server"). Or has enough time passed that we no longer have to care
> about servers which implement slow sync, but not refresh from server?
> Then we could switch to the new behavior unconditionally.
>
> --
> 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.
>
>
>
> _______________________________________________
> os-libsynthesis mailing list
> [email protected]
> http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
