Vincent Beffara writes: > In the meantime I also tweaked the way org-caldav manages UIDs to > exploit the fact that multiply occurring events are now exported > multiple times in ox-icalendar, everything works out well if only > org->ical is used. One thing remaining, on ical->org sync, there is an > issue that makes the next sync erase the event on ical and upload it > again, under another id (and with the info not generated by org-caldav > missing, of course). I think I know how to fix it, just need to find > some time ... > > I will send what works to the list. (In the meantime, David, don't > pull my second pull request, it is not right.)
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
