[SyncEvolution] Broken UTF-8 item passed to backend (was Explicit type 'text/x-vcalendar' specified in command or item meta)

[Patrick Ohly]

On Sun, 2016-10-02 at 23:19 +0200, deloptes wrote:
> Patrick Ohly wrote:
> 
> [old content removed for visibility]
> > 
> > If I understand this right (disclaimer: I'm not intimately familiar with
> > the specs anymore, and have had no time to read up on them), it is the
> > phone which is sending bogus data, right?
> > 
> > Your explanation in https://bugs.freedesktop.org/show_bug.cgi?id=98019
> > shows the broken data after "Parsing", which is the raw data as sent by
> > the phone.
> > 
> > Perhaps it is indeed specific to your phone? Not sure about other N9
> > owners.
> > 
> 
> I am not sure about it. How can I see what is in the message coming from the
> phone? Is syncevolution-log_trm002_003_incoming.xml (attached to the log)
> the internal message or the one sent by the phone?

"incoming" is sent by the phone, so yes, that's the data sent by the
phone.

> Alternatively can we enforce text/calendar instead of text/x-vcalendar?
> I tried setting this in the ini file
> .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini
> but the engine refused with error.

Was it a local error or did it occur after contacting the phone?
Probably the latter.

> I am not even sure that this is OK to
> modify the file and expect to work.

The Synthesis engine is able to exchange data in different formats and
the configuration options control that aspect. However, the peer it
talks to must support the same formats, which is not possible in this
case: in it's DevInf, the N9 only reports "type=text/x-vcalendar,
version=1.0" for its ./calendar data store.

The expected error then is something about "no common format" (not sure
what the wording is).

> However if you compare both approaches versit vs.
> sysync, i would have preferred to have the versit code as a base line.
> Anyway talking about this leads to nothing. We could only try to correct
> the problems we face.

Agreed.

> > And one more point: the N9 uses KCalExtended (or something derived from
> > it, I lost track of the official name) as calendar storage, which
> > probably uses the same code that you present as the better alternative.
> > Isn't that the code then which sends the data with a broken encoding?
> > 
> 
> Yes I think so and this leads me to the question if it is possible to
> enforce text/calendar (iCal) and not as it is per default in the Nokia_N900
> template text/x-vcalendar (vCal).
> If this is doable I can understand why only I complain, besides the fact
> that I use English/German/Bulgarian/Russian and my wife Italian.

It's also possible that N9/N900 users never used the direct syncing of
calendar data over Bluetooth. I think using SyncEvolution on the phone
to sync with some CalDAV server was more popular.

vCalendar is a very limited format and only poorly supports modern
concepts (meeting series, exceptions, time zones). Shoehorning iCalendar
2.0 data into vCalendar 1.0 is problematic.

> Another option would be to set up some cleanup before passing the data to
> the parser. This would be a simple rule replacing ==0D=0A= with a simple =.
> I have never had a chance to look into the scripting options offered by
> syncevolution - is it thinkable/doable?

This might indeed be the best option. Let me check this in more detail.

> Sorry for bothering that much about it. I just have a feeling there is a
> spell over my attempt to sync in the past 10 years, first with opensync and
> now with Syncevolution, I always hit the wall in some way.

I won't comment on OpenSync here. You probably know already why it
didn't work for you and in what state the project has been since they
dropped MultiSync and tried again.

Regarding SyncEvolution: you missed the time when it was under much more
active development. Intel really helped move the project along for a
while (additional developers, QA) and still does to a limited extend
(hosting, a little bit of my time), but mostly the project is now in
maintenance.

Canonical has a much larger business interest in it now; unfortunately
that hasn't really replaced Intel's support in the upstream project.

-- 
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.