[Funambol-discussions] UID + RECURRENCE-ID

[Patrick O. <pat...@gm...>]

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/