From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Beffara Subject: Re: org-caldav can't find org-prepare-agenda-buffers Date: Thu, 14 Mar 2013 01:05:37 +0100 Message-ID: References: <87k3puyri0.fsf@free.fr> <874ngt8mwl.fsf@Rainer.invalid> <87a9qlm24b.fsf@bzg.ath.cx> <87wqtk8tjx.fsf@free.fr> <87zjyg4i8m.fsf@engster.org> <871ubsfqcm.fsf@gmail.com> <87vc944gxn.fsf@engster.org> <87wqtke9sc.fsf@gmail.com> <87mwug4f5y.fsf@engster.org> <87sj48e8n8.fsf@gmail.com> <87ehfs43xl.fsf@engster.org> <877glj374n.fsf@free.fr> <928F746CECE04D56BDF3848A78421121@gmail.com> <87obevcwf2.fsf@gmail.com> <6AFF8646C27C4CE6A358F84B8B62284E@gmail.com> <87fw07cqsd.fsf@gmail.com> <28621C1EBBE544938B988FA134FB5FD0@gmail.com> <63701794CC0B434FA2BFE0233C420D45@gmail.com> <37E4F6B4499C4973BC5FFEB4FDF45533@gmail.com> <87hakh9lzp.fsf@free.fr> <87hakgwea0.fsf@engster.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="51411451_3db012b3_f5c4" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:60513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFvg1-00063t-7q for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 20:05:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFvfx-0005ps-An for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 20:05:45 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:43461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFvfx-0005pk-1J for emacs-orgmode@gnu.org; Wed, 13 Mar 2013 20:05:41 -0400 Received: by mail-wg0-f47.google.com with SMTP id dr13so1494190wgb.2 for ; Wed, 13 Mar 2013 17:05:40 -0700 (PDT) In-Reply-To: <87hakgwea0.fsf@engster.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Vincent Beffara , Julien Cubizolles , emacs-orgmode@gnu.org, Nicolas Goaziou --51411451_3db012b3_f5c4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --51411451_3db012b3_f5c4 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="org-caldav-multi.patch" Y29tbWl0IDI0YjhhNjY2ZjlkN2IwYjEyYTBkNGNiNTkzN2QxNzk1MmE2NDRiMGEKQXV0aG9yOiBW aW5jZW50IEJlZmZhcmEgPHZiZWZmYXJhQGVucy1seW9uLmZyPgpEYXRlOiAgIFRodSBNYXIgMTQg MDA6NTA6MTIgMjAxMyArMDEwMAoKICAgIEFsbG93IG11bHRpcGx5IG9jY3VycmluZyBldmVudHMK CmRpZmYgLS1naXQgYS9vcmctY2FsZGF2LmVsIGIvb3JnLWNhbGRhdi5lbAppbmRleCAwMzgzMzY2 Li43MzQ0NWVlIDEwMDY0NAotLS0gYS9vcmctY2FsZGF2LmVsCisrKyBiL29yZy1jYWxkYXYuZWwK QEAgLTQxMyw3ICs0MTMsNyBAQCBBcmUgeW91IHJlYWxseSBzdXJlPyAiKSkpCiAKIChkZWZ1biBv cmctY2FsZGF2LWdlbmVyYXRlLW1kNS1mb3Itb3JnLWVudHJ5ICh1aWQpCiAgICJGaW5kIE9yZyBl bnRyeSB3aXRoIFVJRCBhbmQgY2FsY3VsYXRlIGl0cyBNRDUuIgotICAobGV0ICgobWFya2VyIChv cmctaWQtZmluZCB1aWQgdCkpKQorICAobGV0ICgobWFya2VyIChvcmctaWQtZmluZCAob3JnLWNh bGRhdi10cmltLXVpZCB1aWQpIHQpKSkKICAgICAod2hlbiAobnVsbCBtYXJrZXIpCiAgICAgICAo ZXJyb3IgIkNvdWxkIG5vdCBmaW5kIFVJRCAlcy4iIHVpZCkpCiAgICAgKHdpdGgtY3VycmVudC1i dWZmZXIgKG1hcmtlci1idWZmZXIgbWFya2VyKQpAQCAtNjA2LDcgKzYwNiw3IEBAIHdoaWNoIGNh biBvbmx5IGJlIHN5bmNlZCB0byBjYWxlbmRhci4gSWdub3JpbmcuIiB1aWQpKQogCTs7IFRoaXMg aXMgYSBjaGFuZ2VkIGV2ZW50LgogCShvcmctY2FsZGF2LWRlYnVnLXByaW50CiAJIDEgKGZvcm1h dCAiRXZlbnQgVUlEICVzOiBDaGFuZ2VkIGluIENhbCAtLT4gT3JnIiB1aWQpKQotCShsZXQgKCht YXJrZXIgKG9yZy1pZC1maW5kIChjYXIgY3VyKSB0KSkpCisJKGxldCAoKG1hcmtlciAob3JnLWlk LWZpbmQgKG9yZy1jYWxkYXYtdHJpbS11aWQgKGNhciBjdXIpKSB0KSkpCiAJICAod2hlbiAobnVs bCBtYXJrZXIpCiAJICAgIChlcnJvciAiQ291bGQgbm90IGZpbmQgVUlEICVzLiIgKGNhciBjdXIp KSkKIAkgICh3aXRoLWN1cnJlbnQtYnVmZmVyIChtYXJrZXItYnVmZmVyIG1hcmtlcikKQEAgLTY0 OCw3ICs2NDgsNyBAQCB3aGljaCBjYW4gb25seSBiZSBzeW5jZWQgdG8gY2FsZW5kYXIuIElnbm9y aW5nLiIgdWlkKSkKICAgOzsgKE1heWJlKSBkZWxldGUgZW50cmllcyB3aGljaCB3ZXJlIGRlbGV0 ZWQgaW4gY2FsZW5kYXIuCiAgICh1bmxlc3MgKGVxIG9yZy1jYWxkYXYtZGVsZXRlLW9yZy1lbnRy aWVzICduZXZlcikKICAgICAoZG9saXN0IChjdXIgKG9yZy1jYWxkYXYtZmlsdGVyLWV2ZW50cyAn ZGVsZXRlZC1pbi1jYWwpKQotICAgICAgKG9yZy1pZC1nb3RvIChjYXIgY3VyKSkKKyAgICAgIChv cmctaWQtZ290byAob3JnLWNhbGRhdi10cmltLXVpZCAoY2FyIGN1cikpKQogICAgICAgKHdoZW4g KG9yIChlcSBvcmctY2FsZGF2LWRlbGV0ZS1vcmctZW50cmllcyAnYWx3YXlzKQogCQkoYW5kIChl cSBvcmctY2FsZGF2LWRlbGV0ZS1vcmctZW50cmllcyAnYXNrKQogCQkgICAgICh5LW9yLW4tcCAi RGVsZXRlIHRoaXMgZW50cnk/ICIpKSkKQEAgLTc3NSw5ICs3NzUsMTUgQEAgUmV0dXJucyBuaWwg aWYgdGhlcmUgYXJlIG5vIG1vcmUgZXZlbnRzLiIKIAkJICAgICAgKGZvcndhcmQtbGluZSAxKQog CQkgICAgICAocG9pbnQpKSkpCiAKKyhkZWZ1biBvcmctY2FsZGF2LXRyaW0tdWlkICh1aWQpCisg ICJSZW1vdmUgZXh0cmEgZXhwb3J0IHByZWZpeGVzIGZyb20gYSBVSUQuCitUaGlzIGlzIHRvIHRh a2UgY2FyZSBvZiBtdWx0aXBseSBvY2N1cnJpbmcgZXZlbnRzLCB0aGUgVUlEIGtlcHQKK2J5IG9y Zy1jYWxkYXYgY29udGFpbnMgVFMyLSBhbmQgc28gb24gYnV0IHRoZSBvcmcgSUQgZG9lc24ndC4i CisgIChyZXBsYWNlLXJlZ2V4cC1pbi1zdHJpbmcgIl5bQS1aXVtBLVpdWzAtOV0/LSIgIiIgdWlk KSkKKwogKGRlZnVuIG9yZy1jYWxkYXYtcmV3cml0ZS11aWQtaW4tZXZlbnQgKCkKICAgIlJld3Jp dGUgVUlEIGluIGN1cnJlbnQgYnVmZmVyLgotVGhpcyB3aWxsIHN0cmlwIHByZWZpeGVzIGxpa2Ug J0RMJyBvciAnVFMnIHRoZSBPcmcgZXhwb3J0ZXIgcHV0cworVGhpcyB3aWxsIHN0cmlwIHByZWZp eGVzIGxpa2UgJ0RMMScgb3IgJ1RTMScgdGhlIE9yZyBleHBvcnRlciBwdXRzCiBpbiB0aGUgVUlE IGFuZCBhbHNvIHJlbW92ZSB3aGl0ZXNwYWNlcy4gVGhyb3dzIGFuIGVycm9yIGlmIHRoZXJlCiBp cyBubyBVSUQgdG8gcmV3cml0ZS4gUmV0dXJucyB0aGUgVUlELiIKICAgKHNhdmUtZXhjdXJzaW9u CkBAIC03ODYsNyArNzkyLDcgQEAgaXMgbm8gVUlEIHRvIHJld3JpdGUuIFJldHVybnMgdGhlIFVJ RC4iCiAgICAgICgocmUtc2VhcmNoLWZvcndhcmQgIl5VSUQ6XFwob3Jnc2V4cC1bMC05XStcXCki IG5pbCB0KQogICAgICAgOzsgVGhpcyBpcyBhIHNleHAgZW50cnksIHNvIGRvIG5vdGhpbmcuCiAg ICAgICAobWF0Y2gtc3RyaW5nIDEpKQotICAgICAoKHJlLXNlYXJjaC1mb3J3YXJkICJeVUlEOlxc KFxccy0qXFwpXFwoW0EtWl1bQS1aXS1cXCk/XFwoLitcXClcXHMtKiQiCisgICAgICgocmUtc2Vh cmNoLWZvcndhcmQgIl5VSUQ6XFwoXFxzLSpcXClcXChbQS1aXVtBLVpdMT8tXFwpP1xcKC4rXFwp XFxzLSokIgogCQkJIG5pbCB0KQogICAgICAgKHdoZW4gKG1hdGNoLXN0cmluZyAxKQogCShyZXBs YWNlLW1hdGNoICIiIG5pbCBuaWwgbmlsIDEpKQpAQCAtOTYyLDcgKzk2OCw3IEBAIElmIENPTVBM RU1FTlQgaXMgbm9uLW5pbCwgcmV0dXJuIGFsbCBpdGVtIHdpdGhvdXQgZXJyb3JzLiIKIAogKGRl ZnVuIG9yZy1jYWxkYXYtZ2V0LWhlYWRpbmctZnJvbS11aWQgKHVpZCkKICAgIkdldCBvcmcgaGVh ZGluZyBmcm9tIGVudHJ5IHdpdGggVUlELiIKLSAgKGxldCAoKG1hcmtlciAob3JnLWlkLWZpbmQg dWlkIHQpKSkKKyAgKGxldCAoKG1hcmtlciAob3JnLWlkLWZpbmQgKG9yZy1jYWxkYXYtdHJpbS11 aWQgdWlkKSB0KSkpCiAgICAgKGlmIChudWxsIG1hcmtlcikKIAkiKENvdWxkIG5vdCBmaW5kIFVJ RCkiCiAgICAgICAod2l0aC1jdXJyZW50LWJ1ZmZlciAobWFya2VyLWJ1ZmZlciBtYXJrZXIpCkBA IC05ODMsNyArOTg5LDcgQEAgSWYgQ09NUExFTUVOVCBpcyBub24tbmlsLCByZXR1cm4gYWxsIGl0 ZW0gd2l0aG91dCBlcnJvcnMuIgogCSAgICAgICAnKGZhY2UgbGluaykpCiAgICAgKGJlZ2lubmlu Zy1vZi1saW5lKQogICAgIChsb29raW5nLWF0ICJVSUQ6IFxcKC4rXFwpJCIpCi0gICAgKG9yZy1p ZC1nb3RvIChtYXRjaC1zdHJpbmcgMSkpKSkKKyAgICAob3JnLWlkLWdvdG8gKG9yZy1jYWxkYXYt dHJpbS11aWQgKG1hdGNoLXN0cmluZyAxKSkpKSkKIAogOzsgVGhlIGZvbGxvd2luZyBpcyB0YWtl biBmcm9tIGljYWxlbmRhci5lbCwgd3JpdHRlbiBieSBVbGYgSmFzcGVyLgogCg== --51411451_3db012b3_f5c4--