Hi, > Supporting the Google Calendar API in org-caldav wouldn't be hard. It's > actually a very clean, RESTful service; much better than CalDAV, in > fact. Just what you would expect from Google. > > However, this is not a technical issue. This is also why I said that > anyone who wants to implement support for the Google Calendar API in > org-caldav should fork it; I won't accept pull requests which implement > that.
Actually I had a look at the API. It is indeed very clean, but there _is_ a technical issue, namely they limit access to a certain number of connections per day, and this is accounted per application rather than per user. Right now it is 10.000 a day, but just listing all events in a single calendar involves paging: for 200 or so events, I had to connect 7 times, and this counts as 7 connections. I have no idea how many org users would actually sync with google using their proprietary API (given there is support), but reaching the limit would be very quick, and very problematic. [Admittedly it is not a technical issue on their side, but it would be on ours, somehow.] > If Google decides to discontinue a well established, IETF-standardized > API in favor of a proprietary one for which there exist no free server > implementations, I will not support that. I think the best solution for > anyone using Google Calendar is to migrate away from that service. Agreed. Now to look for a replacement ... /v PS: In the mean time, for those who sync only from org to gcal, the option of exporting an ics file and hosting it somewhere for google to subscribe to is still available, but it is far from being as good.
