On Mon, 2010-03-01 at 19:47 +0000, Christof Sulzer wrote:
I'm trying to synch calendar data on Nokia N900 with my Desknow
server
(
www.desknow.com) using Syncevolution 0.9.2-4.
I receive the following error after triggering a synchronization :
"SoupTransport Failure:
http://servername/desknow/sync via libsoup:
Internal Server Error".
Log of the Desknow server :
[http-1000-Processor23]SyncServer: Unexpected exception.
org.syncml.SYNCMLParseException: Unexpected Token
[namespace=syncml:devinf,name=CTCap,ext=-1,id=150,type=1,line/column=1/288]
I already contacted Desknow's support and they are telling me
"Syncevolution uses the Synthesis SyncML engine, which DeskNow is
fully compatible with. Make sure it uses SyncML 1.1 protocol".
So is there a way to force Syncevolution to us SyncML 1.1 ?
Nothing straight-forward. Here's something a bit more complicated which
might work. If it does, we can think about making it easier.
* download
http://git.moblin.org/cgit.cgi/syncevolution/plain/src/syncclient_sample_...
* put it onto the N900 in some directory, as normal user, using
the name syncclient_sample_config.xml
* edit that file and insert
<defaultsyncmlversion>1.1</defaultsyncmlversion> somewhere after
<client type="plugin"> and before </client>
* run the "syncevolution --run --sync-property loglevel=4 'server
config name'" command line in the directory where you edited the
file
* if it doesn't work, check the session log (see "syncevolution
--print-sessions") whether the <defaultsyncmlversion> part is in
the config logged there
According to the Synthesis docs for that option, the engine should retry
with a lower protocol version when the 1.2 default doesn't work. I'm not
sure how that is meant to work exactly, because the "Internal Server
Error" gives no indication at all about the root cause and thus should
be treated as fatal error, with no retries. Perhaps it works if the
server fails more gracefully.
--
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.