After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583742 - Port to external libgdata
Port to external libgdata
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Plugins
2.26.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-plugin-maintainers
Evolution QA team
evolution[google]
Depends on:
Blocks:
 
 
Reported: 2009-05-24 19:36 UTC by Philip Withnall
Modified: 2013-09-13 00:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Port the google-account-setup plugin to external libgdata (8.12 KB, patch)
2009-05-24 19:44 UTC, Philip Withnall
none Details | Review
Port the google-account-setup plugin to external libgdata (updated) (8.51 KB, patch)
2010-03-18 23:55 UTC, Philip Withnall
committed Details | Review

Description Philip Withnall 2009-05-24 19:36:34 UTC
Evolution's google-account-setup plugin also needs porting. Patch coming.

+++ This bug was initially created as a clone of Bug #580021 +++

As agreed on the mailing list, I'm porting e-d-s to libgdata[1].

The initial find-and-replace port is complete, and I've pushed it to the libgdata-port branch on git.gnome.org. Basic calendar functionality is working, but there's still work to be done to tidy it up and better use libgdata's features.

[1]: http://live.gnome.org/libgdata
Comment 1 Philip Withnall 2009-05-24 19:44:36 UTC
Created attachment 135278 [details] [review]
Port the google-account-setup plugin to external libgdata

This is a straight port to the external libgdata, not doing anything fancy like making network operations asynchronous.

It can be committed independently of the changes to e-d-s (bug #580021, bug #583374).
Comment 2 Milan Crha 2009-06-18 14:47:40 UTC
Patch seems good on the first look, though I didn't test it. I'm not sure what's the policy of new package requirement, so the final decision is rather going to someone more educated in this part. Maybe Matt? :)
Comment 3 Matthew Barnes 2009-06-21 03:20:03 UTC
Need an pronouncement from the release team on libgdata first, which is scheduled for late July.  And, given that libgdata would be a _required_ dependency (unlike with libgweather, for example), I'd rather wait until after we branch for GNOME 2.28.  (Our policy is that our unstable releases must be buildable on the latest stable GNOME release.  libgdata isn't in the latest stable GNOME release.)

We _may_ branch early for 2.28 though, so we can get a head start on the kill-bonobo and eds-dbus merges.  Still in discussion with release team.
Comment 4 Philip Withnall 2009-06-21 09:54:15 UTC
The only potential problem with that is that Totem will be (optionally) dependent on libgdata for 2.28, and there may be conflicts between e-d-s' internal libgdata and the external one when installed side-by-side. The external libgdata's LT version is higher than e-d-s', but I'm not totally sure if this will solve things.
Comment 5 Matthew Barnes 2009-11-19 22:08:33 UTC
Philip, I've lost track of how things have progressed since summer.  Is the patch in comment #1 still relevant (even if no longer applies cleanly)?  libgdata is an approved external dependency in 2.28, so we can make some headway on this now.

Also, it looks like we're abandoning our Google calendar backend in favor of CalDAV, but the Google addressbook backend is still golden.  Am I right?
Comment 6 Philip Withnall 2009-11-20 00:43:56 UTC
(In reply to comment #5)
> Philip, I've lost track of how things have progressed since summer.  Is the
> patch in comment #1 still relevant (even if no longer applies cleanly)? 
> libgdata is an approved external dependency in 2.28, so we can make some
> headway on this now.

The patch should still be fairly relevant, although there've been some API changes in libgdata since then, and I'm sure it won't apply cleanly as you say.

> Also, it looks like we're abandoning our Google calendar backend in favor of
> CalDAV, but the Google addressbook backend is still golden.  Am I right?

Yeah, the Google Calendar backend changes in the patch on bug #580021 are no longer relevant, but the changes in Evolution in this patch should still be necessary.

The bulk of the changes remain in the Google Address book backend changes in bug #580021. Unfortunately, I've had no time to keep this up to date or test it extensively, due to starting university. I may be able to put some time into this over Christmas, though.
Comment 7 Philip Withnall 2010-03-18 23:55:39 UTC
Created attachment 156522 [details] [review]
Port the google-account-setup plugin to external libgdata (updated)

Here's an updated version which applies to current evo master and is tested to work. It drops Evolution's dependency on the e-d-s libgdata-1.2, and adds a dependency on the external libgdata >= 0.4.0 (the current version is 0.6.2).

Hopefully this can go in fast now that master's out of freeze.
Comment 8 Matthew Barnes 2010-04-07 23:30:26 UTC
This together with the updated patch in bug #580021 seems to work fine for me.

Setting this bug to depend on bug #580021, as the e-d-s patch has to go in first.
Comment 9 Philip Withnall 2010-04-19 17:21:00 UTC
Comment on attachment 156522 [details] [review]
Port the google-account-setup plugin to external libgdata (updated)

commit 7e7a145b8f482ebaca88a0427069166f1f117566
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Mon Sep 28 15:16:14 2009 +0100

    Bug 583742 — Port to external libgdata
    
    Port Google account setup plugin to external libgdata. This drops the
    dependency on libgdata-1.2 from e-d-s, and add a dependency on the external
    libgdata >= 0.4.0. Closes: bgo#583742

 configure.ac                                 |   11 +++--
 plugins/google-account-setup/Makefile.am     |    6 ++-
 plugins/google-account-setup/google-source.c |   73 +++++++++++++------------
 3 files changed, 49 insertions(+), 41 deletions(-)