On Thu, 2012-09-06 at 22:53 +0200, Ove Kåven wrote:
Den 06. sep. 2012 21:03, skrev Justus-bulk(a)Piater.name:
> Ove Kåven <ovek(a)arcticnet.no> wrote on Thu, 06 Sep 2012 20:29:02 +0200:
>> It's probably just HTML. There's no reason that couldn't be synced.
>> suppose that ideally, the sync format would then be text/html rather
>> than text/plain, but I don't think SyncML knows the difference, it's
>> probably all text/plain to it.)
> Would seem likely. However, the markup is apparently lost already
> upstream: The syncevolution-log_trm*_*_outgoing.xml show the notes in
> plain-text form, with no markup. Also, fwiw, the (adware) Harmattan app
> "Notes Exporter" produces plain-text output.
OK, but perhaps the markup *would* be synced if you were able to use
text/calendar instead of text/plain. I've just taken a look, and it
seems the markup is stored in the X-ALT-DESC property of the iCal entry.
You can see what it looks like if, on your N9, you dump the notes
database with a command like:
$ syncevolution --export - <config> memo
You could also take a look at your trm* logs when you try to sync memos
with text/calendar format, to see if there's an X-ALT-DESC property sent
to the PC (before the PC fails to parse it).
Patrick, would the engine handle this?
No, not yet. In contrast to --import/export, which exchanges items with
the backends directly, syncing first translates into an internal
description (the field list). This is necessary for the translation
between vCalendar 1.0 and iCalendar 2.0, or iCalendar 2.0 and plain
X-ALT-DESC is not currently stored and thus gets neither sent nor is it
preserved when writing back into the Harmattan storage.
Regarding sending: what should it be mapped to at the receiving end? It
can be encoded again as X-ALT-DESC;FMTTYPE=text/html, but that will only
be useful for Harmattan<->Harmattan syncs or Harmattan<->file backend.
The problem is that if the peer doesn't know about it and just changes
the plain text description, then DESCRIPTION and X-ALT-DESC will become
Therefore preserving X-ALT-DESC locally must become more intelligent
than "always preserve it". It needs to know whether the peer really
supported the X-ALT-DESC and updated it together with the DESCRIPTION
and if not, needs to check whether the DESCRIPTION was modified.
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.