Hi, Agreed ... I believe the only problem will occur when one of a multiply occurring event is edited / deleted on the cal side. I have nothing more constructive to propose than just "don't do that" ... My use-case is just as a way to push org changes to cal and nothing more, and for bidirectional people who would create events on cal and sync, not much bad would happen I believe. But you're right, conflict resolution (which is what that would be) will be a problem. Would have to manage reference counts etc, for little benefit. Who is using multiply occurring events anyway? Attached is what I am proposing: absent multiply occurring events, the org and cal IDs are the same (which is as it was except for the missing 1 in a regexp). For the second occurrence, the TS2- prefix is conserved, and so on - but it is trimmed when fed to org-id etc. As you say, it is not correct and will lead to problems down the road, but I really wanted all occurrences to appear in iCal ;-) Cheers, /v > I appreciate your work, of course, but let me add a word of warning. I > think if you give up the one-to-one correspondence that one Org event > has exactly *one* event in the remote calendar, you are entering a world > of pain. > > Remember that there are three things: new items, changed items and > deleted items. Since these can happen on both sides, you have to figure > out six different cases which must be handled properly. As you've > already experienced, the changes on the calendar side are more > difficult. What happens if you delete one of the events that stems from > one Org entry? You would first have to figure out which timestamp > created it, but how? Timestamps don't have UIDs, only the full entry has > one. So you would have to somehow add this information to the event > database which gets stored to disk. You might get this to work, but I > have a gut feeling that you'll loose robustness. For example, the Google > calendar CalDAV interface is pretty slow and not very reliable, so a > robust resume functionality is essential. > > Also, I deliberately shoved conflict handling at the side for the > moment, but this is a feature which will have to be added one day, and > will complicate things much more. > > -David