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

[deloptes]

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.

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

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

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.

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

I thought it might be added by sysync after opening the wbxml or whatever.
But if you say it is unmodified as sent by the phone, I'll buy it.
I have not looked into the scripting options before/after etc., but it looks
like an option for a work around.

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

Since we discussed the topic in 2011, I was dragged in a couple of big
projects ... also a big private project called family+child took place :)
It also became clear that I will not use the newer KDE and I was hoping that
someone else will do the "dirty" work and write the plugins for TDE/KDE3 :)

Anyway, I don't know what interest Intel or Canonical have in this project.
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.

Thanks

_______________________________________________
SyncEvolution mailing list
SyncEvolution at syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution