6:58 p.m.
Hi!
I am facing an issue syncong to a SyncML server (yes - umpf - Horde ;)
from my N900.
The initial sync (refresh-from-client) from the N900 (with
Syncevolution) to the server works just fine - excellent! All entries
appear and seem to be correct.
So far so fine.
Changes made on the N900 are also properly detected and synced to the
server.
Great!
But when I make a change on the server the change is properly detected
- one item is to be synced. But the sync fails:
–
* [2010-11-04 18:43:51.053] Remote sent replace-operation:
* [2010-11-04 18:43:51.053] - Source: remoteID ='', remoteName=''
* [2010-11-04 18:43:51.054] - Target: localID ='15', remoteName=''
* [2010-11-04 18:43:51.054] Explicit type 'text/x-s4j-sifc'
specified in command or item meta
* [2010-11-04 18:43:51.054] According to remote devInf,
'text/x-s4j-sifc' is not supported, but obviously it is used here so we
try to handle it
* [2010-11-04 18:43:51.055] Incompatible content type
'text/x-s4j-sifc' version '[none]' specified in command or item meta
* [2010-11-04 18:43:51.055] processSyncOpItem: Error while
processing item, status=415
* [2010-11-04 18:43:51.055] Irregularity in execution of item,
status=415
I have to admit I have never ever seen or heard about "text/x-s4j-sifc"
so I have no clue what this is about. I tried to google for it but found
amazingly nothing that would give even the slightest clue ;)
Does someone here on the list have an idea? Or even a possible workaround?
PS: If I delete an entry on the server it is also deleted without error
from the N900. so only changes cause this error.
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
8:59 p.m.
On Do, 2010-11-04 at 17:58 +0000, Nils Faerber wrote:
But when I make a change on the server the change is properly
detected
- one item is to be synced. But the sync fails:
–
* [2010-11-04 18:43:51.053] Remote sent replace-operation:
* [2010-11-04 18:43:51.053] - Source: remoteID ='', remoteName=''
* [2010-11-04 18:43:51.054] - Target: localID ='15', remoteName=''
* [2010-11-04 18:43:51.054] Explicit type 'text/x-s4j-sifc'
specified in command or item meta
* [2010-11-04 18:43:51.054] According to remote devInf,
'text/x-s4j-sifc' is not supported, but obviously it is used here so we
try to handle it
* [2010-11-04 18:43:51.055] Incompatible content type
'text/x-s4j-sifc' version '[none]' specified in command or item meta
* [2010-11-04 18:43:51.055] processSyncOpItem: Error while
processing item, status=415
* [2010-11-04 18:43:51.055] Irregularity in execution of item,
status=415
I have to admit I have never ever seen or heard about "text/x-s4j-sifc"
so I have no clue what this is about.
The Horde server is not configured correctly. It sends the client
calendar data in an out-dated Funambol XML format.
Does someone here on the list have an idea? Or even a possible
workaround?
This has come up before, but I don't remember what the exact solution
was. If Google doesn't help, then please ask the Horde developers.
--
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.
10:33 a.m.
Am 04.11.2010 20:59, schrieb Patrick Ohly:
On Do, 2010-11-04 at 17:58 +0000, Nils Faerber wrote:
[...]
> I have to admit I have never ever seen or heard about
"text/x-s4j-sifc"
> so I have no clue what this is about.
The Horde server is not configured correctly. It sends the client
calendar data in an out-dated Funambol XML format.
Does this also apply to the contacts? Because the same happens with
contacts - N900->Horde works, but not in the other direction.
It also works perfectly well with other Nokia phones, we tested an E61.
Now here comes my ignorance: I read "between" the lines here on the
mailinglist that basically Syncevolution negotiates dataformats and
profiles with the syncml partner. There also are config options in the
sync sources (like calendar) to hardy-fix some of those formats (like
using icalendar V2.something).
Is there probably something that I can do on the N900 side to force
Horde into another mode?
> Does someone here on the list have an idea? Or even a possible
workaround?
This has come up before, but I don't remember what the exact solution
was. If Google doesn't help, then please ask the Horde developers.
OK, I'll try to Google for it and also try to look at the Horde again
(probably try to find some)
CHeers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
12:28 p.m.
On Fr, 2010-11-05 at 09:33 +0000, Nils Faerber wrote:
Am 04.11.2010 20:59, schrieb Patrick Ohly:
> On Do, 2010-11-04 at 17:58 +0000, Nils Faerber wrote:
[...]
>> I have to admit I have never ever seen or heard about
"text/x-s4j-sifc"
>> so I have no clue what this is about.
>
> The Horde server is not configured correctly. It sends the client
> calendar data in an out-dated Funambol XML format.
Does this also apply to the contacts? Because the same happens with
contacts - N900->Horde works, but not in the other direction.
That might be the same problem.
Now here comes my ignorance: I read "between" the lines
here on the
mailinglist that basically Syncevolution negotiates dataformats and
profiles with the syncml partner. There also are config options in the
sync sources (like calendar) to hardy-fix some of those formats (like
using icalendar V2.something).
SyncEvolution/Synthesis support that, but Horde doesn't. It basically
detects the peer and then picks one format for sending. That goes wrong
here.
Is there probably something that I can do on the N900 side to force
Horde into another mode?
You might check your deviceId. That was a workaround that worked a while
ago, but it should be in the code. Hmm, perhaps the N900 port still has
that problem? The workaround was released as part of 1.0 beta 2.
commit 185a33d3415a6156c9bcf7ee120566aa9b91983a
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Feb 19 16:13:43 2010 +0100
deviceId: use syncevolution- prefix, helps Horde (MB #9347)
Previously we used "sc-pim-" as prefix for our device ID because
my.FUNAMBOL depended on it for distinguishing phones from other
devices. It supported only one phone, but multiple others. Without
the right prefix it would do slow syncs when switching between
different clients.
This behavior was changed, which allows us to use our own prefix.
That solves a problem with Horde, which treated our client like
an old, broken Funambol client because of the prefix and then
sent us calendar items in the old Funambol SIF-C format instead
of vCalendar/iCalendar.
Released as part of 1.0 beta 2.
--
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.
1:26 p.m.
Am 05.11.2010 12:28, schrieb Patrick Ohly:
On Fr, 2010-11-05 at 09:33 +0000, Nils Faerber wrote:
> Am 04.11.2010 20:59, schrieb Patrick Ohly:
>> On Do, 2010-11-04 at 17:58 +0000, Nils Faerber wrote:
> [...]
>>> I have to admit I have never ever seen or heard about
"text/x-s4j-sifc"
>>> so I have no clue what this is about.
>>
>> The Horde server is not configured correctly. It sends the client
>> calendar data in an out-dated Funambol XML format.
>
> Does this also apply to the contacts? Because the same happens with
> contacts - N900->Horde works, but not in the other direction.
That might be the same problem.
It was, yes ;) (see below)
> Now here comes my ignorance: I read "between" the lines
here on the
> mailinglist that basically Syncevolution negotiates dataformats and
> profiles with the syncml partner. There also are config options in the
> sync sources (like calendar) to hardy-fix some of those formats (like
> using icalendar V2.something).
SyncEvolution/Synthesis support that, but Horde doesn't. It basically
detects the peer and then picks one format for sending. That goes wrong
here.
OK.
> Is there probably something that I can do on the N900 side to
force
> Horde into another mode?
You might check your deviceId. That was a workaround that worked a while
ago, but it should be in the code. Hmm, perhaps the N900 port still has
that problem? The workaround was released as part of 1.0 beta 2.
This was it, yes!
I now use something like:
deviceId = sc-api-nat-<identifier>
which you proposed earlier on the SyncEvo Wiki:
http://syncevolution.org/wiki/Horde
(I should have read that earlier!).
commit 185a33d3415a6156c9bcf7ee120566aa9b91983a
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Fri Feb 19 16:13:43 2010 +0100
deviceId: use syncevolution- prefix, helps Horde (MB #9347)
Hmm... would that make a diference in contrast to sc-api-nat-... ?
Cheers
nils
--
kernel concepts GbR Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de
8:23 a.m.
On Fr, 2010-11-05 at 12:26 +0000, Nils Faerber wrote:
I now use something like:
deviceId = sc-api-nat-<identifier>
which you proposed earlier on the SyncEvo Wiki:
http://syncevolution.org/wiki/Horde
(I should have read that earlier!).
> commit 185a33d3415a6156c9bcf7ee120566aa9b91983a
> Author: Patrick Ohly <patrick.ohly(a)intel.com>
> Date: Fri Feb 19 16:13:43 2010 +0100
>
> deviceId: use syncevolution- prefix, helps Horde (MB #9347)
Hmm... would that make a diference in contrast to sc-api-nat-... ?
No, I don't think so. As long as Horde does not mistake us for a old
Funambol client, everything should be fine. However, I'm only guessing.
The Horde developers would know for sure.
--
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.
3678
days inactive
3682
days old
syncevolution@synevolution.org
5 comments
2 participants
participants (2)
-
Nils Faerber -
Patrick Ohly