On Fri, 2012-06-01 at 09:10 +0300, Andris Pavenis wrote:
On 05/31/2012 04:01 PM, Patrick Ohly wrote:
> Hello!
>
> Let me add the Synthesis list where compatibility with the Funambol
> client is also currently getting discussed.
I have at least some success with Funambol Client from Android market
About says:
FunV10 Version 10.1.3
1) added datastore 'configuration'. Due to absence of hints what to use
took copy/paste from 'notes' and edited name after that
2) workarounded XML parse errors in SyncML TK by converting XML to
WBXML using libwbxml (tests done on Fedora 16, libwbxml version
0.11.0). After that I'm getting error message about NULL dereference
from Funambol client log on Android phone. Suspected that even when
client provided 'Accept-Encoding: gzip' it failed to decode gzip
compressed
message (server returned 'Content-Encoding: x-gzip')
This doesn't apply to the Funambol client which Onyeibo Oku was testing,
which still used XML. I could try to replicate it in syncevo-http-server
(a Python script which provides the HTTP front-end), if there is some
real need for it.
3) Added a diagnostic feature to server to disable compression of
outgoing
messages even if client says it is OK to compress. After enabling this
diagnostic feature and specifying correct remote datastore names on
FunV10 client synchronization finally works
One additional note:
Funamol uses different data-store names as Synthesis clients by default.
data-store name alias support would be nice feature to have in libsynthesis.
In our (IPNetworks) server development version such alias support is already
implemented on data-store level, but then one must copy/paste related
sections in server XML configuration files. Something like
<datastore name="contacts" type="plugin">
...
<alias name="card"/>
would look much nicer.
Something like that exists already:
11.34.1 <alias>: alternate name for this datastore
Contained in: <datastore> of <server>
Can contain: alternate data store name
Attributes: none
Default: none
This can be used to make the same datastore accessible with an alternate name. In scripts
the
LOCALDBNAME() function (see 11.34.21) can be used to find out what name was used by the
remote (client) to address the datastore – and possibly behave differently depending on
what
name was used.
However, I noticed a problem with it that I still need to investigate
further: DevInf only includes the main name of a datastore. A peer which
expects a different name can sync if that different name was set as
alias, but it will have to do so without matching CTCaps. I've seen
warnings in the Synthesis logs about "blind syncs" because of that.
--
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.