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

[Vincent Beffara]

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

org-caldav-multi.patch
Description: Binary data