On Mon, 2013-05-20 at 17:42 +0200, Christof Schulze wrote: > Hello, > > Am Montag, 13. Mai 2013, 22:30:58 schrieb Lukas Zeller: > > Hello Patrick, > > > On 23.04.2013, at 18:17, Patrick Ohly <[email protected]> wrote: > > > On Wed, 2013-04-17 at 17:12 +0200, Lukas Zeller wrote: > > > One more question, to you and/or Christof: in your experience, how > > > quickly do phones give up? In other words, what is the recommended value > > > of <requestmaxtime>? > > > > I'm currently considering to make one minute the default for all HTTP > > > clients. > > > Years ago, the device that caused me implementing this was the Ericsson T68i > > which had no more than 30 seconds "patience". > > > Looking at the default config of the server, it seems that we settled on 120 > > seconds for the global <requestmaxtime>. However it is possible to set a > > per-device <requestmaxtime> in the remote rule. Curiously, the T68i in the > > sample config does not set 30 seconds, though. Maybe later revisions had a > > more generous timeout, or nobody used that device ever again... > Does that mean I can already set a larger timeout for my nokia e51? > Say... 2 hours?
Not in the normal SyncEvolution, because it didn't use the feature that Lukas described. But in the meantime I have implemented the necessary changes (thread-safety, config option) in SyncEvolution, so when compiling from source it is possible. Hmm, I thought I had sent you an email about that, but I can't find it. If you want a tar ball, try this: http://downloads.syncevolution.org/tmp/syncevolution-1.3.99.3%2b20130514%2bSE%2bde24470%2bunclean%2bSYSYNC%2b3366831.tar.gz It should use the feature by default. The full documentation is this: '--sync-property SyncMLVersion=?' On a client, the latest commonly supported SyncML version is used when contacting a server. One of '1.0/1.1/1.2' can be used to pick a specific version explicitly. On a server, this option controls what kind of Server Alerted Notification is sent to the client to start a synchronization. By default, first the format from 1.2 is tried, then in case of failure, the older one from 1.1. 1.2/1.1 can be set explicitly, which disables the automatism. Instead or in adddition to the version, several keywords can be set in this property (separated by spaces or commas): - NOCTCAP - avoid sending CtCap meta information - NORESTART - disable the sync mode extension that SyncEvolution client and server use to negotiate whether both sides support running multiple sync iterations in the same session - REQUESTMAXTIME=<time> - override the rate at which the SyncML server sends preliminary replies while preparing local storages in the background. This helps to avoid timeouts in the SyncML client. Depends on multithreading. This SyncEvolution binary is thread-safe and thus this feature is enabled by default for HTTP servers, with a delay of 2 minutes between messages. Other servers (Bluetooth, local sync) should not need preliminary replies and the feature is disabled, although it can be enabled by setting the time explicitly. <time> can be specified like other durations in the config, for example as REQUESTMAXTIME=2m. Setting these flags should only be necessary as workaround for broken peers. -- 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
