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

Reply via email to