setting the right evolution version 

The bug #543069 is one for CalDAV, very similar to your bug #508496, where, for CalDAV, doesn't work detached instances for recurring events. I'm on it.
I'm still not much sure with the Google calendar backend drop, maybe someone will take care of it.

I'm CC'ing Philip to get his opinion.

After hours of slow bugzilla I managed to log in :-)

Thank you very much for your understanding, 

@mrcha: i don't see any problems left with cal dav support, but I'll keep on watching the othe bug report too.

@ Andre / Philip: thanx for taking the time to read this wish, I hope you've got the same opinion like me that gnome - evolution shouldn't be the test field for indivual solutions, but useable for daily needs.

Milan, As you have been working on the Caldav front, how is google calendar support through caldav ? If its good enough, we could drop the google calendar backend as the developer is inactive and would not be active in the future too...

Expected that I got the password questions for each calendar this time all seems to be find.

and there is: http://bugzilla.gnome.org/show_bug.cgi?id=543069 but I'm quite not sure what this is about


PS: @ Milan, so posted on launchpad that he doesn't get the password form since he created a new PGP key,
are there writing issues to the gnome-keyring?

(In reply to comment #5)
> Milan, As you have been working on the Caldav front, how is google calendar
> support through caldav ? If its good enough, we could drop the google calendar
> backend as the developer is inactive and would not be active in the future
> too...

It works fine pretty well for me, but would be better to ask real users. Interestingly enough, it is suffering with the very same issue as the Google backend for the detached instances of recurring events, but as I said, I'm on it.

(In reply to comment #6)
> PS: @ Milan, so posted on launchpad that he doesn't get the password form since
> he created a new PGP key,
> are there writing issues to the gnome-keyring?

There was pushed a fix for this recently, see bug #578335

What about not dropping the google calendar fully, only using CalDAV backend, but have the account setup same? I believe people would appreciate list of subscribed calendars and easier way to define their calendar than searching for some weird URL around the Internet.

Milan, I noticed now that i can't delete on event which is part of a recurring series.

(In reply to comment #9)
> Milan, I noticed now that i can't delete on event which is part of a recurring
> series.

Yes, that makes detached instance, thus is part of bug #543069

(In reply to comment #3)
> I'm CC'ing Philip to get his opinion.

Looking at the known issues page for Google Calendar's CalDAV support[1], everything looks quite nice. I'd be all for using CalDAV to synchronise with Google calendars, rather than libgdata (whether e-d-s' internal copy, or my external library). Does this mean I should stop my work in porting the e-d-s Google Calendar backend to the external libgdata (bug #580021)?

[1]: http://www.google.com/support/calendar/bin/answer.py?answer=99360

(In reply to comment #11)
> Does this mean I should stop my work in porting the e-d-s Google Calendar
> backend to the external libgdata (bug #580021)?

I wouldn't kill it entirely just yet, but maybe put it aside for now.

(In reply to comment #12)
> I wouldn't kill it entirely just yet, but maybe put it aside for now.

I suppose I could work on porting Evo's google-account-setup plugin instead then.

I agree with Matt, do some testing and such before dropping it fully. I just realized that I cannot create meetings in a Google account when I'm not an organizer. I consider it incorrect, though I do not have any idea where to report to them. I've also other issues with my calendar there, not only when using CalDAV, but that's totally different thing :)

(In reply to comment #11)
> (In reply to comment #3)
> > I'm CC'ing Philip to get his opinion.
> 
> Looking at the known issues page for Google Calendar's CalDAV support[1],
> everything looks quite nice. I'd be all for using CalDAV to synchronise with
> Google calendars, rather than libgdata (whether e-d-s' internal copy, or my
> external library). Does this mean I should stop my work in porting the e-d-s
> Google Calendar backend to the external libgdata (bug #580021)?
> 
> [1]: http://www.google.com/support/calendar/bin/answer.py?answer=99360
> 

Porting to libgdata would be always good. It would be good to have the all api's for accessing google in a single package. You can continue if your interest is to make the library available for all apps.. Evolution can use the libgdata library for google-account-setup plugin.

Philip, btw why do u want to port account-setup plugin to libgdata ? I think it might mostly contain Evolution specific code. Creating ESources etc.

Milan, the calendar setup code can still be there. I just mentioned about the backend part.

(In reply to comment #15)
> Philip, btw why do u want to port account-setup plugin to libgdata ? I think it
> might mostly contain Evolution specific code. Creating ESources etc.

It does mostly contain Evolution-specific code, but it uses e-d-s' internal libgdata library to retrieve a list of possible calendars from Google. This is what needs replacing with the external libgdata. It's bug #583742, and I've already attached a patch.

It seems the caldav can also read remote calendars, and even make new, though the interface in evo is quite tight to not allow that from the calendar preferences.

Created attachment 137333 [details] [review]
proposed eds patch

for evolution-data-server;

Necessary changes to ESource to let this work. Notice that calling e_source_set_absolute_uri twice had no effect the second and next call.
Also my recent changes in e_source_update_from_xml_node weren't as that correct.

Created attachment 137334 [details] [review]
proposed evo patch

for evolution;

The plugin change. I removed the SSL setup and I'm forcing it to use SSL, as Google's CalDAV requires that.

Created commit 5bb20ac in eds master (2.27.4+) with CalDAV changes:
 - store CTag at the fully finished sync, not before
 - listen for ESource changes
 - less aggressive locking
 - sync can be interrupted
 - create/modify/remove operations have precedence before the sync

I also plan to give back the progressive sync, which I changed some time ago. As it is now, it is working, but it can be better for large calendars. Definitely question for other bug, though.

Milan, I am able to retrieve the calendar events using google-account-setup plugin through caldav. will play more with caldav on google and we can decide on getting this in.

*** Bug 583800 has been marked as a duplicate of this bug. ***

Milan, It would be great if you can put down the feature parity at higher level between what google calendar backend provides and caldav would provide as we had a discussion in irc..

I’m wondering if the "CalDAV Know Issue"[1] about alerts can be avoided with this approach.

Email or SMS reminders don't sync

    Apple's iCal, Mozilla Sunbird, and Google Calendar differ in the types of event reminders
    offered. While Google Calendar supports pop-up, email, and SMS reminders, iCal and
    Sunbird only support pop-up reminders. Accordingly, only pop-up reminders are synced 
    between Google Calendar and these calendar applications.

I find these two alert types most useful.

[1] http://www.google.com/support/calendar/bin/answer.py?answer=99360

(In reply to comment #24)
> I’m wondering if the "CalDAV Know Issue"[1] about alerts can be avoided with
> this approach.
> 
> Email or SMS reminders don't sync

Partially, I see evolution reads the email notifications properly, but some static capability might be added for google calendar to indicate it supports it fully. With respect of SMS reminders, my google calendar doesn't offer me such option, might be because I do not share with them my cell phone number.

(In reply to comment #23)
> Milan, It would be great if you can put down the feature parity at higher
> level between what google calendar backend provides and caldav would
> provide as we had a discussion in irc..

Testing on actual master, thus 2.27.4:
- Time zone handling
   - GBackend shifts new events by ~4 hours (a bug report for that exists)
   - correct on CalDAV, as far as I can tell (++)
- Recurrence events
   - GBackend doesn't support it (a bug report for that exists)
   - is fixed in CalDAV now
- Cache
   - GBackend doesn't show events from the server (see below)
   - CalDAV updates new events based on the server
   (Notice Google server modifies events on creation, like you've setup there
   some default alarm, then it's added even you created an event without it.
   It modifies also timezone definitions, to use locations only)
   - GBackend seems to download "all" events every time
   - CalDAV, after initial fetch, checks for changed events only
- Alarms
   - GBackend drops alarms on sync with a server
   * CalDAV works for popup and email alarms
- Events
   - Cannot create with GBackend, they are turned to meetings on a fetch
   - CalDAV works fine
- Meetings
   - GBackend changes organizer to the account owner every time
   * CalDAV cannot create with organizer different from the account owner (it
     returns "Authentication failed", thus probably forcing account owner as
     an organizer might help here.)
- Meeting requests
   - GBackend pretends all is fine, but server item has no attendees and
     an organizer is changed as well
   * CalDAV cannot save a meeting request for a meeting organized by someone
     else. As far as I can tell it's an issue with Google server, as when you
     receive such request on the google mail account, then it works fine
- Attachments
   - Google server doesn't seem to support attachments on events at all
- Tasks
   - Even Google server started to support tasks, they didn't allow that
     for CalDAV connections (as of today). I do not expect any obstacles
     with respect of this when they start to provide a DAV connection for it

One advantage with CalDAV is that the all ugly work with transferring iCal component into GData and back is done on Google server, not like in GBackend, thus it requires less work on our side.

Those above marked with "*" are supposed to take some attention.
Chen, what about doing them in iteration, than resending patches here all over?

------------------------------------------------------------------------------

Hmm, I hope I didn't forget anything. Also, my tests were very simple, someone might try to check that up too, probably.

------------------------------------------------------------------------------

(++) I was noted by a user with a bad issue with timezones, Google server doesn't seem to support any custom timezone, but only those locations known for them. As an example, if you've set Asia/Ho_Chi_Minh in Evolution, then you will not be able to create an event with CalDAV, with the only error on console: "Could not create the object!" (no UI error shown). The Google server only returns "404 Not Found" and nothing else. It seems to work with GBackend, but it isn't. The evo UI shows the Asia/Ho_Chi_Minh timezone, but the server item, as returned from the server by CalDAV, has set the default timezone of the calendar as set on the server.

Going through everything, it is definetly better to move to caldav interface. 
Just want to clarify one thing here and we can go ahead with committing the patches.

- Meeting requests
   - GBackend pretends all is fine, but server item has no attendees and
     an organizer is changed as well
   * CalDAV cannot save a meeting request for a meeting organized by someone
     else. As far as I can tell it's an issue with Google server, as when you
     receive such request on the google mail account, then it works fine

When I receive a meeting from some-one else (me being attendee), will I be able to accept the meeting request ? Also receive the updates properly if the organizer changes details of the meeting ?

I tested the behaviour again, just to be sure (and as we talked on IRC) with this result:
- I can accept it in the google mail WebUI and then the event is added, with
  the proper organizer.
- Then I deleted the event and tried the same with the evo only, through caldav,
  and it doesn't want to add the event to the calendar, "Unable to send item
  to calendar 'googlin'.  Authentication failed"

I'm not sure whether I do anything wrong, but the same event with just a different organizer works fine (different ~~ same as the account owner). From my point of view it is an issue with their implementation of caldav, but, I'm not sure. I only know that the same works fine with zzzimbra and davical.

As I hear that GcalBackend also suffers from the same. We can have a separate bug filed for this on caldav and fix it up. Am approving the patch considering the fixes/features which caldav backend adds comparing with gcal backend. 

We will still have the google calendar backend code until evolution-3.0 and once we are sure its ok to remove the gcal backend code, we can go ahead with that.

Created commit 1564ac6 in eds master (2.27.5+)
Created commit 143695d in evo master (2.27.5+)

Created follow-up bugs:
  bug #588856 - for migration code
  bug #588857 - email notifications
  bug #588858 - meetings and organizers

*** Bug 531317 has been marked as a duplicate of this bug. ***