7:14 p.m.
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 <patrick.ohly(a)intel.com> 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%...
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.