[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 00:31 +0200, deloptes wrote:
> Patrick Ohly wrote:
> 
> > On Tue, 2016-09-27 at 08:57 +0200, deloptes wrote:
> >> Patrick Ohly wrote:
> >> 
> >> > On Mon, 2016-09-26 at 23:01 +0200, deloptes wrote:
> >> 
> >> >> 
> >> >> Hi,
> >> >> I hope you have not forgotten about this problem. Please look into my
> >> >> last message and let me know if I can do something more. If it is the
> >> >> same issue as the TDE/libkcal one, the fix should be really simple.
> >> > 
> >> > There was a misunderstanding: I need you to re-run the sync as
> >> > explained above (loglevel=4 as command line parameter), and *then* the
> >> > resulting log html file will have more information. The one you sent
> >> > doesn't include information about the detailed item conversion.
> >> > 
> >> 
> >> Might be my bad - sorry.
> >> 
> >> Here
> >> [2016-09-27 08:51:45.496] Created new item of datatype 'vCalendar10',
> >> localID='' remoteID='526'
> >> 
> >>
> DESCRIPTION;ENCODING=QUOTED-PRINTABLE;CHARSET=utf-8:=D0=A2=D0=B5=D1=81=D1=82
> >> =D0=B4=D1=8A=D0=BB=D0=B3=D0=BE =D0=BE=D0=BF=D0==0D=0A=
> >> =B8=D1=81=D0=B0=D0=BD=D0=B8=D0=B5 =D0=B7=D0=B0
> >> =D0=B7=D0=B0=D0=B4=D0=B0==0D=0A=
> >> 
> >> Note ==0D=0A=
> >> 
> >> It is also visible in syncevolution-log_trm002_003_incoming.xml
> > 
> > Sorry, I'm still confused about what the actual, unmodified incoming
> > data is. Can you attach the entire log file?
> > 
> > I doubt that I will have time to fix this, but at least I should be able
> > to reproduce it and point you into the right direction in the code.
> > 
> 
> 
> Looking into the synthesis quoted-printable parser .... it's really a
> brainf**k. I'm just wondering if I am the only one on this planet to have
> such issues doing a sync with UTF-8 encoded text.

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 was expecting to find something like the versit parser, which I think is
> really nice in KDE3/TDE[1], but I found here something self written, not
> based on grammar ... and giving me a lot of headache.
> Very very sad story!

Before you get worked up too much about this: remember that this parser
has to support plenty of different formats (not just the modern
revisions of the standard with sane rules for encoding, but also old
ones, like vCalendar, which are terribly inconsistent), and data from
peers which don't follow the standard. Having to support such a mess is
not leading to nice code.

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?

> The diff is the closest I could get to make it work acceptable for me - it
> at least does not mangles the text.
> 
> [1] https://git.trinitydesktop.org/cgit/tdepim/tree/libkcal/versit
> 
> I hope it helps come to some solution.

I fear I need to sit down and study this more before I can do anything
about this. Please don't hold your breath.

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