Some folks have been using the free version of this plugin for several years. Some of them have recurring events with modified instances. Sometimes the frequency of modifications is high. In the last few months this has caused a fair bit of extra support required as anomalies crop up. Sometimes bugs are flushed out and sometimes almost unanswerable questions are raised as to what the plugin should do if it gets weird data.
The point of this post is to highlight some of the complexities that may develop and urge you to keep your ics files as clean as possible or use amr-events where it is possible to delete old events (hard to delete volumes of old events in google calendar).
An example is modifications to recurring rules or rdates and modifications to instances of those recurring rules (themselves already a modification.)
For example:Assume we have a recurring event. It starts with a SEQUENCE: 0
DTSTART;VALUE=DATE:20140421 RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=3MO UID:1f4irrb5uh6q3cdfsnq15vd00g_R20140421@google.com SEQUENCE:0
This generates an infinite set of mondays, including the following
- 19th May
- 16th June
- 21 July
- 18 August
- etc
Now, one of the instances gets modified. (This could be just the description or the actual date.) A RECURRENCE-ID VEVENT is created for each instance modification and the SEQUENCE NO is updated. The recurrence-id matches the date in the recurring rule that it applies to. The combination of UID, RECURRENCE-ID and SEQUENCE helps us identify the instance that is being updated.
For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed.
DTSTART;VALUE=DATE:20140721 (ie no date change in this example) DTSTAMP:20140720T064853Z UID:1f4irrb5uh6q3cdfsnq15vd00g_R20140421@google.com RECURRENCE-ID;VALUE=DATE:20140721
Now assume the original RRULE is modified too, perhaps just the description or shock horror, the recurring date definition? It’s sequence-no is updated too BUT now what should happen to the RECURRENCE-ID instance? Should it be updated to indicate it is still valid? IE we now have:
- generated date 21 July 2014 with UID and SEQUENCE = 3 and
- RECURRENCE-ID;VALUE=DATE:20140721 with matching UID and SEQUENCE = 3
It appears that perhaps SEQUENCE numbers can increment separately, so one could conceivably receive a file with a RRULE with an equal to or greater sequence number than a RECURRENCE-ID. From this discussion, it is really not clear what the supplying calendar application will do:
Once UID 1/SEQUENCE 0 hits UID 1/SEQUENCE 1 (which would mean something significant about the set of instances has changed) all bets are off in regards to RECURRENCE-ID values that previously existed.
If the UID/RECURRENCE-ID/SEQUENCE matches a generated date from the rrule with same SEQUENCE (ie both have been modified), then what? One cannot just use eg: LAST-MODIFIED:20140620T200327Z. Who is to say that a mod of the RRULE was intended to overwrite the RECURRENCE instance? Quite possibly not.
What does the plugin do:
For now (until further authoritative input to the contrary), the plugin will assume that a recurring instance (RECURRENCE-ID) in the file is intended to be still there. It will include the highest sequence number of the recurrence (even if the originating rrule is not there -an error in supplying application). Similarly it will include the recurrence even if the rrule does not have a matching date.
It will also assume that the recurrence instance overwrites the RRULE definition even if the RRULE has a later SEQUENCE number. The Plugin does not have to worry about the complications of syncing for now.
If you are ever struggling to figure out what the plugin has done. Create a test list and include the RECURRENCE-ID and SEQUENCE fields. You can reference the test lits by adding ?listtype=x to your events page url.
Clik here to view.
Some lengthy related discussions here and in other parts of the thread:
- http://www.imc.org/ietf-calendar/mail-archive/msg05681.html (recurrence-ids fixed ?)
- http://www.imc.org/ietf-calendar/mail-archive/msg05696.html (Independent Sequence Numbers)
Complications that urge one to keep events as simple as possible:
Searching the web seems to indicate some folks believe RECURRENCE-IDS should not change. So should we assume that if the RECURRENCE-ID vevent is still in the file then it is still valid and should be included. (What does this mean for syncing and deletions? IE How does one ‘delete’ an existing event. Or should one always delete events from an ics file and reload ONLY what’s in the ics file?)