On Thu, 2012-09-06 at 22:53 +0200, Ove Kåven wrote: > Den 06. sep. 2012 21:03, skrev justus-b...@piater.name: > > Ove Kåven <o...@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. (I > >> 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 text. 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 inconsistent. 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. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
