Re: [SyncEvolution] Sony Ericsson C510: No idea to get it working
On Mo, 2010-11-01 at 20:02 +0000, knipp(a)m-otion.com wrote:
Hi Patrick,
On Mon, 1 Nov 2010, Patrick Ohly wrote:
> That means "not found" - whatever wasn't found might be visible in
the
> logs. Can you share a log with the settings that at least triggered
> synchronization on the phone?
I already sent an email containing log and settings, but without success,
the message is too big and needs approval by the list moderator.
Sorry, public holiday here today, so I'm not reading all of my email.
Normally I would have noticed and approved it.
So, I've put the files on http://ravenea.m-otion.at/~knipp
That shows that the phone is sending an incorrect Alert command:
[2010-11-01 14:04:56.664] - Processing Alert Item (code=201),
Source='Contacts', Target=''
Note the empty "Target" value. That's supposed be our URI, sent to the
phone earlier in the SAN message (not logged). For comparison, a Nokia
phone correctly sends us that:
[2010-11-01 13:56:00.470] - Processing Alert Item (code=200),
Source='/telecom/pb.vcf', Target='Contacts'
I already tried „Contact“ as given by the template, „Contacts“ as
seen as
SourceRef in the response from the phone and „card3“ as read in the wiki
for another Sony phone. I even tried to set the uri property to an empty
string.
Just to be sure, is that "empty string" test perhaps where the empty
value came from in the log above?
If the phone always sends an empty string, then I can think of a
reasonably easy (?) workaround: fall back to the Source value when the
Target is empty.
Interestingly I cannot find the value of the uri property somewhere
in the
syncevolution-log.html nor in the XML files.
If you log with an even higher log level (say 10), then you'll see the
Synthesis XML config which contains <datastore> entries with these URIs
as aliases.
The SAN message in SyncML 1.2 also contains it, but it is not logged.
--
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.