(In reply to comment #0)
> Currently, Calendar is able to sync with Google with the fallback EDS provider.
> We should give special love to Google one.

Care to elaborate here?

Sure. As you can state in Google's Developer page for Calendar API [1], "as of version 3.0, the Google Calendar API uses JSON data objects instead of the GData format." This conflicts with the current implementation of EDS' Google backend, which uses libgdata.

While it works reasonably well, we shouldn't rely on deprecated technologies, and that's why I'm proposing the development of a custom data provider for Google. This can be achieve by:

- creating a specific Google-driver provider with the JSON format.
- creating a WebDAV provider, since Google also allows Calendar to be accessed this way.

[1] https://developers.google.com/google-apps/calendar/

(In reply to comment #2)
> Sure. As you can state in Google's Developer page for Calendar API [1], "as of
> version 3.0, the Google Calendar API uses JSON data objects instead of the
> GData format." This conflicts with the current implementation of EDS' Google
> backend, which uses libgdata.
> 
> While it works reasonably well, we shouldn't rely on deprecated technologies,
> and that's why I'm proposing the development of a custom data provider for
> Google. This can be achieve by:
> 
> - creating a specific Google-driver provider with the JSON format.
> - creating a WebDAV provider, since Google also allows Calendar to be accessed
> this way.
> 
> [1] https://developers.google.com/google-apps/calendar/

From that point, we should encourage people and other developers to improve the whole GNOME stack. Meaning it would be better to improve the eds backend for Google Calendar to not use gdata and use instead the newer API.

Agreeing with eds developers we could start an implementation here and move it into eds when they agree is in the right shape for doing it.

See my point?

Indeed, this is more an EDS bug than Calendar.

Thanks for a bug report.

(In reply to Georges Basile Stavracas Neto from comment #2)
> This conflicts with the current implementation of EDS'
> Google backend, which uses libgdata.

This statement is not true, evolution-data-server doesn't use libgdata for Google's Calendar, it uses CalDAV for several years now (I do not know what your 'current eds version' is, but the current stable is 3.16.0, with 3.12.11 being the current few days ago).

From that point there is nothing to be done on the EDS side.

More generally, more sense would make to enhance libgdata, to use the new JSON API, and keep its users using the same front-end API, thus having this protocol change transparent to the libgdata clients. After all, why would users know anything about used protocols and choosing between them?

The corresponding libgdata bug report is bug #664353, thus I mark this as a duplicate of it.

*** This bug has been marked as a duplicate of bug 664353 ***