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

[Patrick Ohly]

On Tue, 2016-10-04 at 23:03 +0200, deloptes wrote:
> Thank you for the extended explanations in your reply.
> 
> Patrick Ohly wrote:
> 
> [old content removed for visibility]
> 
> > 
> >> 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 think it was a 10500 error.

The log then probably had a better explanation, but I'm sure it was what
I described.

> >> 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).
> > 
> 
> So once again, please confirm. The configured "type=text/x-vcalendar" in 
> .config/syncevolution/default/peers/nokia_n9/sources/calendar+todo/config.ini
> does not enforce the phone to respond, rather it is based on the
> capability - correct?

Correct. Basically SyncEvolution starts a sync by telling the phone what
data stores it wants to sync, and then the phone describes what kind of
data formats it accepts for those stores. SyncEvolution does the same,
and then both sides decide based on the received information in which
format they send data.

SyncEvolution can try to coerce a peer to send data in a certain format
by only listing that format as supported, but that only works if the
peer supports that format and checks the information sent by
SyncEvolution. I only know of one SyncML implementation that supports
this, and that is the Synthesis engine used by SyncEvolution.

> > 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.
> > 
> 
> It looks to me that indeed it only supports "type=text/x-vcalendar",
> although I would expect text/calendar by KCalExtended. I think I have
> somewhere sources - I'll try to dig a bit.

There's a bit of history, too, here: there were discussions to use
SyncEvolution as SyncML implementation in MeeGo (which would have given
you iCalendar support also for SyncML), but Nokia preferred their
in-house implementation (which is limited to vCalendar). That
implementation is what you are talking to now.

> Anyway, I don't know what interest Intel or Canonical have in this project.

Intel was using SyncEvolution for example in Moblin Netbooks and more
recently for phone support in Tizen IVI. Canonical is using
SyncEvolution for data synchronization in Ubuntu, mostly the phone
flavor.

> It looks like a very good work so far and I hope whoever works on this
> further will maintain this level. Even this parser seem to work well if it
> gets the right data, no matter how ugly it looks. 
> 
> Last but not least, you are also really nice and helpful.

I still feel responsible for SyncEvolution and definitely want to ensure
that users who have an interest in it have the possibility to use it.
But as in your case, there's also real life and family, so the situation
is different now compared to previous years.

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