Hello,
> If you want a tar ball, try this: http://downloads.syncevolution.org/tmp/syncevolution-1.3.99.3%2b20130514%2bS > E%2bde24470%2bunclean%2bSYSYNC%2b3366831.tar.gz > It should use the feature by default. The full documentation is this: I finally managed to use some spare cpu cycles to compile this version. When Running it however the debug log shows upon connect: [DEBUG] syncevo-http: processing incoming message of type application/vnd.syncml+wbxml and length 404, binary data [DEBUG] syncevo-http: requesting new session [ERROR] twisted: Unhandled Error Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349, in dataReceived finishCallback(data[contentLength:]) File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563, in _finishRequestBody self.allContentReceived() File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618, in allContentReceived req.requestReceived(command, path, version) File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773, in requestReceived self.process() --- <exception caught here> --- File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132, in process self.render(resrc) File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167, in render body = resrc.render(self) File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 216, in render return m(request) File "/usr/local/bin/syncevo-http-server", line 299, in render_POST urlparse.urljoin(self.url.geturl(), request.path)) File "/usr/local/bin/syncevo-http-server", line 205, in start self.object = Context.getDBusServer() File "/usr/local/bin/syncevo-http-server", line 89, in getDBusServer '/org/syncevolution/Server'), File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/local/libexec/syncevo-dbus-server exited with status 127 [DEBUG] twisted: 213.211.221.128 - - [29/Jun/2013:21:19:09 +0000] "POST /sync HTTP/1.1" 500 11880 "-" "Nokia SyncML HTTP Client" Needless to say - there is no sync working. How can I get a more useful error message than "unhandled Error"? Regards Christof Am Montag, 20. Mai 2013, 21:14:35 schrieb Patrick Ohly: > > 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. > '--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 2minutes > 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. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
