|
From: Patrick O. <pat...@gm...> - 2012-06-20 07:07:59
|
Hello! I did another full test run between SyncEvolution<->OneMedia. I still have some issues with 417 "retry later"; the affected tests intentionally do a slow sync to check how well pairing works on the server. I guess I'll have to disable that part of the testing with Funambol. Another test involves two VEVENTs. In one SyncML session, the server is asked to Add the parent item of an event series by client A: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:STANDARD DTSTART:19671029T030000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:19870329T020000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20120619T135553Z DTSTAMP:20120619T135603Z CREATED:20120619T135553Z UID:20080407T193125Z-19554-727-1-50@gollum SEQUENCE:1 CLASS:PUBLIC TRANSP:OPAQUE SUMMARY:Recurring DESCRIPTION:recurs each Monday\, 10 times DTSTART;TZID=Europe/Berlin:20080406T090000 RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=SU;UNTIL=20080608T090000 DTEND;TZID=Europe/Berlin:20080406T093000 END:VEVENT END:VCALENDAR http://syncev.meego.com/2012-06-19-13-21_testing_funambol/testing-amd64/22-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.recv-parent.client.B/syncevolution-log_trm002_003_outgoing.xml A check with a second client confirms that the event was stored, with ID 212862834: http://syncev.meego.com/2012-06-19-13-21_testing_funambol/testing-amd64/22-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.recv-parent.client.B/syncevolution-log_trm003_006_incoming.xml Then in the next session of client A, the server is asked to Add a detached recurrence: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.41//EN BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:STANDARD DTSTART:19671029T030000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:19870329T020000 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20120619T135637Z DTSTAMP:20120619T135646Z CREATED:20080407T193241Z UID:20080407T193125Z-19554-727-1-50@gollum SEQUENCE:1 CLASS:PUBLIC TRANSP:OPAQUE SUMMARY:Recurring: Modified DESCRIPTION:second instance modified DTSTART;TZID=Europe/Berlin:20080413T090000 RECURRENCE-ID;TZID=Europe/Berlin:20080413T090000 DTEND;TZID=Europe/Berlin:20080413T093000 END:VEVENT END:VCALENDAR http://syncev.meego.com/2012-06-19-13-21_testing_funambol/testing-amd64/22-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.send-child.client.A/syncevolution-log_trm002_003_outgoing.xml A check (= two-way sync) with client B shows that the item was added, but the RECURRENCE-ID got lost. http://syncev.meego.com/2012-06-19-13-21_testing_funambol/testing-amd64/22-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.recv-child.client.B/syncevolution-log_trm003_006_incoming.xml BEGIN:VCALENDAR VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT DTSTART:20080330T020000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:Europe/Berlin END:DAYLIGHT BEGIN:STANDARD DTSTART:20081026T030000 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:Europe/Berlin END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:20080407T193125Z-19554-727-1-50@gollum SUMMARY:Recurring: Modified DESCRIPTION:second instance modified CLASS:PUBLIC DTSTART;TZID=Europe/Berlin:20080413T090000 DTEND;TZID=Europe/Berlin:20080413T093000 X-FUNAMBOL-ALLDAY:0 END:VEVENT END:VCALENDAR Because the UID was preserved and client B cannot store two different events with the same UID, it'll replace the parent event and later ask the server to do the same => data loss. This test passed with the older myFunambol; here's a copy of the SyncEvolution 1.2.1 test results: http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-2-1/2011-11-25-14-34_syncevo=syncevolution-1-2-branch_all/testing-amd64/nightly.html#funambol The data that got was is similar, but the server did not preserve the UID and thus both events could be stored. http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-2-1/2011-11-25-14-34_syncevo=syncevolution-1-2-branch_all/testing-amd64/14-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.send-parent.client.A/syncevolution-log_trm002_003_outgoing.xml http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-2-1/2011-11-25-14-34_syncevo=syncevolution-1-2-branch_all/testing-amd64/14-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.send-child.client.A/syncevolution-log_trm002_003_outgoing.xml http://downloads.syncevolution.org/syncevolution/archive/test-results/syncevolution-1-2-1/2011-11-25-14-34_syncevo=syncevolution-1-2-branch_all/testing-amd64/14-funambol/Client_Sync_eds_event_testLinkedItemsParentChild.recv-child.client.B/syncevolution-log_trm003_006_incoming.xml Supporting UID is a step in the right direction. It would give Funambol a real edge over competitors because finally it would be possible again to synchronize iCalendar 2.0 without data loss. However, at the moment, without RECURRENCE-ID, the support is incomplete and causes a worse kind of problem for users who have detached recurrences (= basically anyone working in a larger organization with many meeting series): instead of loosing the connection between different VEVENTs, they loose entire instances. Do you have plans to support both UID and RECURRENCE-ID? I could work around this by stripping the UID from incoming items from the Funambol server, but to which server versions should that be applied? If I do this for all versions, then I will have to release a new SyncEvolution once you implement UID+RECURRENCE-ID and users will have to update - not likely to happen in lockstep with your server update. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |