9:19 p.m.
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?
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. I am not even sure that this is OK to
modify the file and expect to work.
> 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.
Yes, I understand this! 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.
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.
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?
> 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.
No, it is just a reference. You have the RFC, the yacc grammar and the
parser code. You can just go through the readme to get an idea. If this was
the base for the sysync parser, things would be much easier.
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 now changed the code as posted in the diff, to at least have some readable
text, however I noticed that ',' is displayed as '\,' and new line chars
are also double escaped, but I don't want to dig into it right now.
I understand that this is not the correct way or place to handle this, so
this diff is not a patch, but to show where it breaks.
And thank you for the good help so far.
regards