On Thu, 2014-07-31 at 17:29 +0200, Thomas Pequet wrote: > Le 28/07/2014 10:43, Patrick Ohly a écrit : > > Hello Thomas! > Hello Patrick > > > > I am currently testing the following change in SyncEvolution: > > > > commit 662aab0823905d56edf812cf5bf2464379fdfcaf > > Author: Patrick Ohly <[email protected]> > > Date: Wed Jul 23 14:07:13 2014 +0200 > > > > EDS: memo syncing as iCalendar 2.0 (FDO #52714) > > > > When syncing memos with a peer which also supports iCalendar 2.0 as > > data format, the engine will now pick iCalendar 2.0 instead of > > converting to/from plain text. The advantage is that some additional > > properties like start date and categories can also be synchronized. > > > > The code is a lot simpler, too, because the EDS specific iCalendar 2.0 > > <-> text conversion code can be removed. > > > > With Memotoo that only works partially. Adding a new note on the server > > using iCalendar 2.0 as format works. Updating it fails: the server seems > > to ignore the new data. > > > > I also noticed that the server sends broken CtCap if (and only if!) the > > client mentions iCalendar 2.0. Memotoo then lists > > <Rx-Pref><CTType>text/calendar</CTType> and > > <Rx><CTType>text/plain</CTType> but then describes some unrelated > > <CTCap><CTType>text/x-vnote</CTType> > Ok thanks Patrick for this bug :) > I have corrected this problem. Tell me if it is not OK.
I can confirm that the CtCap is okay now. However, the main problem of memo updates in text/calendar format getting ignored by the server still exists. Latest logs here: https://nightly.syncevolution.org/2014-07-31-11-21_testing-amd64_memotoo_eds_memo/testing-amd64/39-memotoo/ > > Here's the sync where a note gets updated: > > https://nightly.syncevolution.org/2014-07-25-22-25_all/testing-amd64/39-memotoo/Client_Sync_eds_memo_testAddUpdate.recv.client.B/syncevolution-log.html > > First message sent by client: > > https://nightly.syncevolution.org/2014-07-25-22-25_all/testing-amd64/39-memotoo/Client_Sync_eds_memo_testAddUpdate.recv.client.B/syncevolution-log_trm001_001_outgoing.xml > > Broken CtCap from server: > > https://nightly.syncevolution.org/2014-07-25-22-25_all/testing-amd64/39-memotoo/Client_Sync_eds_memo_testAddUpdate.recv.client.B/syncevolution-log_trm001_002_incoming.xml > > Update sent by client: > > https://nightly.syncevolution.org/2014-07-25-22-25_all/testing-amd64/39-memotoo/Client_Sync_eds_memo_testAddUpdate.update.client.A/syncevolution-log_trm002_003_outgoing.xml > > > > This is what a second client then later gets: > > https://nightly.syncevolution.org/2014-07-25-22-25_all/testing-amd64/39-memotoo/Client_Sync_eds_memo_testAddUpdate.recv.client.B/syncevolution-log.html > > https://nightly.syncevolution.org/2014-07-25-22-25_all/testing-amd64/39-memotoo/Client_Sync_eds_memo_testAddUpdate.recv.client.B/syncevolution-log_trm003_006_incoming.xml > > -- 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 [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
