emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] org-caldav can't find org-prepare-agenda-buffers


From: David Engster
Subject: Re: [O] org-caldav can't find org-prepare-agenda-buffers
Date: Tue, 12 Mar 2013 21:31:51 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux)

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

[Prev in Thread] Current Thread [Next in Thread]