Re: [O] org-caldav for Google or Zimbra?
Jason Riedy ja...@lovesgoodfood.com writes: Does anyone have org-caldav working with the new Google endpoint Can you expand on this? I am not sure what you mean by endpoint. I use org-caldav-sync several times a day and it generally works very well with Google's calendar service. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.1.1-7-gaecdf5
Re: [O] org-caldav for Google or Zimbra?
And Eric S. Fraga writes: Can you expand on this? I am not sure what you mean by endpoint. I use org-caldav-sync several times a day and it generally works very well with Google's calendar service. Google has deprecated the URL in org-caldav, and that old URL does not work for me. The new one is documented at https://developers.google.com/google-apps/calendar/caldav/v2/guide#new_endpoint Fiddling with the regexp in org-caldav-events-url triggers an error apparently in the authentication code: Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil) url-http-handle-authentication(nil) url-http-parse-headers() url-http-chunked-encoding-after-change-function(415 440 25) url-http-wait-for-headers-change-function(1 453 452) url-http-generic-filter(#process apidata.googleusercontent.com HTTP/1.1 401 Unauthorized\nWWW-Authenticate: Bearer realm=\https://www.google.com/accounts/AuthSubRequest\\nContent-Type: text/html; charset=UTF-8\nDate: Thu, 26 Sep 2013 13:48:37 GMT\nExpires: Thu, 26 Sep 2013 13:48:37 GMT\nCache-Control: private, max-age=0\nX-Content-Type-Options: nosniff\nX-Frame-Options: SAMEORIGIN\nX-XSS-Protection: 1; mode=block\nServer: GSE\nAlternate-Protocol: 443:quic\nTransfer-Encoding: chunked\n\ne\nLogin Required\n0\n\n) accept-process-output(#process apidata.googleusercontent.com) #[0 \302\303\300@!)\207 [(#process apidata.googleusercontent.com) inhibit-quit nil accept-process-output] 2 \n\n(fn)]() funcall(#[0 \302\303\300@!)\207 [(#process apidata.googleusercontent.com) inhibit-quit nil accept-process-output] 2 \n\n(fn)]) url-retrieve-synchronously(https://apidata.googleusercontent.com/caldav/v2/jason.riedy/events/;) url-http-options(https://apidata.googleusercontent.com/caldav/v2/jason.riedy/events/;) url-dav-supported-p(https://apidata.googleusercontent.com/caldav/v2/jason.riedy/events/;) (if (url-dav-supported-p (org-caldav-events-url)) nil (error The URL %s does not seem to accept DAV requests (org-caldav-events-url))) org-caldav-sync() eval((org-caldav-sync) nil) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp nil nil) Someone on github reported the same issue. -- Jason
Re: [O] org-caldav for Google or Zimbra?
Jason Riedy writes: Google has deprecated the URL in org-caldav, and that old URL does not work for me. The new one is documented at https://developers.google.com/google-apps/calendar/caldav/v2/guide#new_endpoint Fiddling with the regexp in org-caldav-events-url triggers an error apparently in the authentication code: Google has changed authentication on the new endpoint to OAuth. Julien has written an OAuth2 client implementation, which is in GNU ELPA, but I didn't have time to look at it yet. Not sure when I get to it; I hope someone beats me to it. -David
Re: [O] org-caldav for Google or Zimbra?
And David Engster writes: Google has changed authentication on the new endpoint to OAuth. Julien has written an OAuth2 client implementation, which is in GNU ELPA, but I didn't have time to look at it yet. Not sure when I get to it; I hope someone beats me to it. Ok, well understood. Thank you! -- Jason
[O] org-caldav for Google or Zimbra?
Does anyone have org-caldav working with the new Google endpoint or Zimbra? The former errors out (there's an issue on github, but I don't want a github account to ask there), and the latter uses a different URL scheme... Zimbra's URL scheme is https://server.example.com/dav/username/calendarname with a calendarname is Calendar. Special-casing org-caldav-events-url for my server appears to work. Feels like that function could be over-ridden per server / target org file, but I'm not quite sure what the right granularity should be. Hm. Perhaps having each synced calendar in a separate org file might work. Each org file could set some file-wide parameters like calendar URL. -- Jason, who no longer has relevant papers on file...
