GNOME Bugzilla – Bug 664353
Upgrade to Calendar API version 3
Last modified: 2015-05-27 23:00:14 UTC
Version 3 with its shiny new JSON interface is available. Versions 1 and 2 of the API will be deprecated in 3 years. http://googleappsdeveloper.blogspot.com/2011/11/introducing-next-version-of-google.html
The old API appears to be have been revoked on November 17th, as promised: http://googleappsupdates.blogspot.com/2014/06/calendar-gdata-api-google-calendar.html Is there any work being done on version 3?
(In reply to comment #1) > Is there any work being done on version 3? Not so far. I haven’t had time, and wasn’t aware anyone was still using the libgdata API after Evo switched to CalDAV. Are you using it?
California uses libgdata for probing Google Calendar for the user's calendars. After that, it uses CalDAV (via EDS) for the actual calendaring operations. Evolution 3.12.8 has this 403 FORBIDDEN problem. Browsing git master, it appears their google-cal-config still uses gdata the way California does: https://git.gnome.org/browse/evolution/tree/modules/cal-config-google/e-google-chooser.c#n459 I'm guessing EDS is affected by this too.
(In reply to comment #3) > California uses libgdata for probing Google Calendar for the user's calendars. > After that, it uses CalDAV (via EDS) for the actual calendaring operations. > > Evolution 3.12.8 has this 403 FORBIDDEN problem. Browsing git master, it > appears their google-cal-config still uses gdata the way California does: > > https://git.gnome.org/browse/evolution/tree/modules/cal-config-google/e-google-chooser.c#n459 > > I'm guessing EDS is affected by this too. Yeah, that’s correct. Bother. I won’t have time to fix this (it’s a pretty in-depth fix involving rewriting most of the Calendar service) for a few weeks. Would you be able to spent time on it? I can provide pointers.
It's possible I could lend a hand, but right now I'm weighing that versus simply using the CalDAV protocol to fetch the calender list from Google. That would kill two birds with one stone, as we have requests to support CalDAV probing for non-Google calendars. How much work do you think it would be? Is this JSON-style approach used elsewhere in the library, or would this be breaking new ground, so to speak? And since this affects Evolution as well, does it make sense to bring them into this conversation and see what their take is?
(In reply to comment #5) > It's possible I could lend a hand, but right now I'm weighing that versus > simply using the CalDAV protocol to fetch the calender list from Google. That > would kill two birds with one stone, as we have requests to support CalDAV > probing for non-Google calendars. Does CalDAV probing work for Google servers? IIRC when Evolution switched to CalDAV, they had to retain GData for the probing, as it wasn’t supported using CalDAV. That may have changed. > How much work do you think it would be? Is this JSON-style approach used > elsewhere in the library, or would this be breaking new ground, so to speak? libgdata supports JSON, so it would be a matter of porting the XML parsing/generating code in the Calendar backend to use JSON instead. I would estimate a couple of days to a week. > And since this affects Evolution as well, does it make sense to bring them into > this conversation and see what their take is? I suspect their solution will be the same as yours, but I’ve CCed Milan.
(In reply to comment #6) > Does CalDAV probing work for Google servers? Yes, Google supports it. Users can create their Google calendars as CalDAV directly, where clicking Find Calendars button lists all their defined calendars from which they can choose. > IIRC when Evolution switched to > CalDAV, they had to retain GData for the probing, as it wasn’t supported using > CalDAV. That may have changed. That's true (and proved above at comment #3). The libgdata is used only for the Google calendar type. Evolution didn't switch to full CalDAV-based interface for Google calendar type configuration yet. It's not a high priority, you know. (In reply to comment #3) > Evolution 3.12.8 has this 403 FORBIDDEN problem. Browsing git master, it > appears their google-cal-config still uses gdata the way California does: Hmm, that's new to me. I see that when creating a new Google calendar, I suppose it goes from libgdata, maybe the page newly requires OAuth authentication only? In any case, when I edit the created Google calendar I get a CalDAV editor, which is sort of bug in the code, but as far as the CalDAV interface supports all what is needed (search for calendars on the server), then it won't hurt. The CalDAV calendar properties also gives more options to users.
(In reply to comment #7) > Hmm, that's new to me. I see that when creating a new Google calendar, I > suppose it goes from libgdata, maybe the page newly requires OAuth > authentication only? In any case, when I edit the created Google calendar I get > a CalDAV editor Yeah, I was talking about adding a new Google calendar, not editing an existing one. There's a third way I thought of over the weekend, but have not spend two seconds exploring in the code. One hurdle with the CalDAV approach is that the application needs to generate an OAuth token and go through Google's flaming rings of security fire. Could libgdata provide that and then California/Evolution use the authorization for straight CalDAV? I'm beginning to wonder if GOA is going to be a key component to solving this problem.
(In reply to comment #8) > One hurdle with the CalDAV approach is that the application needs to > generate an OAuth token and go through Google's flaming > rings of security fire. Not true as of today. Accessing https://www.google.com/calendar/dav/[user]@gmail.com/events/ with user name + password (or an application specific password in the case of the two-factor authentication) still works.
(In reply to comment #8) > I'm beginning to wonder if GOA is going to be a key component to solving this > problem. It is currently the only way how to get OAuth tokens in evolution-data-server. I plan to change it, but it's nothing small and as such will take its time (future feature).
(In reply to comment #9) > > One hurdle with the CalDAV approach is that the application needs to > > generate an OAuth token and go through Google's flaming > > rings of security fire. > > Not true as of today. I was looking at this page: https://developers.google.com/google-apps/calendar/caldav/v2/guide#connecting_to_googles_caldav_server Perhaps they will support non-OAuth traffic for the indefinite future; that certainly would be easier. I just worry that going this route is simply buying a little more time until they turn off that access point, and we're back in this hole again.
(In reply to comment #11) > Perhaps they will support non-OAuth traffic for the indefinite future; that > certainly would be easier. I just worry that going this route is simply buying > a little more time until they turn off that access point, and we're back in > this hole again. Yeah, from my experience, Google are definitely standardising on OAuth 2.0 and other auth backends are starting to get unmaintained. I suspect they will be dropped eventually.
Been working on other things and would like to return to this after the holiday season. I looked at the link Milan pointed to. This does indeed return the user's primary VCALENDAR, but that's not exactly the problem this ticket is concerned with. What we need is a way to enumerate all the calendars available to the user, either created by them or those they have access to. Is there a way with this access point to get that list?
(In reply to comment #13) > Is there a way with this access point to get that list? 'This access point' like 'with CalDAV'? It currently works here in a way that the Google's CalDAV interface returns all configured calendars in the Google's Web UI. Thus whatever a user sees in the Web UI can be detected with the CaldAV interface. I think it's the same what libgdata interface offered.
I have a WIP branch to port to the V3 API. Probably will not get it finished until after the New Year. http://cgit.collabora.com/git/user/pwith/libgdata.git/log/?h=calendar-v3
*** Bug 741922 has been marked as a duplicate of this bug. ***
*** Bug 742798 has been marked as a duplicate of this bug. ***
Just for a record, evolution uses CalDAV interface to get list of available Google calendars now [1]. To be released as 3.15.91 (after 3.13.90, to sync with the GNOME versioning). [1] https://git.gnome.org/browse/evolution/commit/?id=219c5f7
*** Bug 740847 has been marked as a duplicate of this bug. ***
I'm unable to use california, I get it is the same auth api problem ? Do a fix in libgdata will also bring california and geary to work ? Is a fix targeted with a specific release of gnome, or could libgdata be fixed in the current versions of gnome ?
This is now mostly fixed. The bulk of the API has been ported from v2 to v3, with the big exception being ACL support. The unit tests are currently in a terrible state, but will be updated. Remaining things to do before this bug can be closed: • Port ACL support • Abstract calendar insertion (so we use gdata_calendar_service_insert_calendar() rather than gdata_service_insert_entry()) • Proofread the documentation • Update the unit tests commit 0e42b9d0e64aaf9f4d04eeab29d860a68209ff61 Author: Philip Withnall <philip@tecnocode.co.uk> Date: Mon May 4 00:11:34 2015 +0100 demos: Add calendar-cli demo This is a simple demo to allow querying calendars and events from the command line, and inserting simple new events into a calendar. Makefile.am | 32 ++++++- demos/calendar/calendar-cli.c | 535 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 566 insertions(+), 1 deletion(-) commit 83d215b9d2bb7e7b1547986c23277b370fce215f Author: Philip Withnall <philip@tecnocode.co.uk> Date: Mon May 4 00:08:50 2015 +0100 calendar: Port to the Calendar API version 3 Deprecated API: • GDataCalendarFeed:timezone, gdata_calendar_feed_get_timezone() • GDataCalendarFeed:times-cleaned, gdata_calendar_feed_get_times_cleaned() • GDataBatchable implementation in GDataCalendarService • gdata_calendar_service_insert_event(), gdata_calendar_service_insert_event_async() • GDataCalendarCalendar:times-cleaned, gdata_calendar_calendar_get_times_cleaned() • GDataCalendarCalendar:edited, gdata_calendar_calendar_get_edited() API changes: • GDataBatchable implementation in GDataCalendarService will now always fail • ACLs are temporarily not supported; support for them will be re-added in future when they have been ported to the new API • Add gdata_calendar_service_insert_calendar_event(), gdata_calendar_service_insert_calendar_event_async() This includes a partial update of the unit tests, but most of them have been disabled pending updates. https://bugzilla.gnome.org/show_bug.cgi?id=664353 docs/reference/gdata-sections.txt | 2 + gdata/gdata.symbols | 2 + gdata/services/calendar/gdata-calendar-calendar.c | 311 +++++++++++++++++------------- gdata/services/calendar/gdata-calendar-calendar.h | 9 +- gdata/services/calendar/gdata-calendar-event.c | 846 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------- gdata/services/calendar/gdata-calendar-feed.c | 91 +++------ gdata/services/calendar/gdata-calendar-feed.h | 8 +- gdata/services/calendar/gdata-calendar-query.c | 3 +- gdata/services/calendar/gdata-calendar-service.c | 514 +++++++++++++++++++++++++++++++++++++++----------- gdata/services/calendar/gdata-calendar-service.h | 36 +++- gdata/tests/calendar.c | 696 ++++++++++++++++++++++++++++++++++++++++--------------------------- 11 files changed, 1775 insertions(+), 743 deletions(-)
Created attachment 304116 [details] [review] calendar: Re-enable support for ACLs with version 3 of the API This was non-trivial. New API added: • GDataCalendarAccessRule Due to how this new class overrides GDataAccessRule, it must be used in place of GDataAccessRule for any interactions with the Calendar API. This is essentially a soft API break for anyone who uses calendars. It’s unavoidable.
All done. Attachment 304116 [details] pushed as 68ed77f - calendar: Re-enable support for ACLs with version 3 of the API