Closed Bug 1570933 Opened 5 years ago Closed 5 years ago

investigate moving Gdata provider calendar usage to CalDAV

Categories

(Calendar :: Provider: GData, task)

Product:
Calendar
Component:
Provider: GData
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: mkmelin, Unassigned)

Details

It's apparent GData has a bunch of gotchas and problems for Calendar usage (e.g. bug 1288098). Google also provides the CalDAV interface for accessing calendars. That doesn't support Tasks however.

We should investigate if we can basically drop Gdata, and migrate users over to the CalDAV interface. This would be removing non-needed code, and moving to using standards instead of internal google apis.

Component: General → Provider: GData

Given users expect task to be part of the package, and it is a driving force behind many users using gdata, just dropping gdata is not really a way forward. It is one step forward and one back.

Perhaps what could be done is actually down size gdata to just include tasks. Make all google calendars caldav and just a rump of gdata that can be a tasks provider. That would avoid the duplication for calendars and meet the expectations of current users and future ones that task will be synchronised.

There are a few features of calendaring that are available in the gdata provider but not exposed through the caldav protocol. This includes but is not limited to tasks. There may certainly be a few bugs in the gdata provider, but I don't think that is sufficient reason to merge the two. I'd prefer to keep the Provider for Google Calendar separate.

It is a bit early as there is still so much to do, but since this subject is on the table now, I think it is a good time to share my vision with you.

Long story short: I would like to take over the gdata provider, remove it from the thunderbird source and turn it into a google provider AddOn for TbSync, merged with gContactSync to provide simple setup for google contacts, tasks and events using the google API.

As Magnus knows, Ryan asked me about a year ago to add TbSync to Thunderbird core as a new central place to manage cloud accounts and I have been working on that ever since. I have now a clean code base and the provider API added by TbSync looks very good now as well. That provider API allows other AddOns to hook into TbSync and add sync capabilities. Currently there are Exchange Active Sync and CalDav/CardDAV. The second one is actually only adding CardDAV support and delegates caldav sync to lightning, but it is doing resource discovery (so users do not have to add the individual urls, but only need the base server address).

The next logical step would be to add a google provider. I hope to get the author of gContactSync onboard, but I haven't asked yet.

I will try to get TbSync into TB76. The next step here would be to get in touch with Alex, on how to integrate TbSync into the new UI. In general TbSync will know wich Provider exists and can load them as needed, so the user does not need to know, where to get the needed provider addons.

If you want to try out TbSync, to get a feeling for this vision, please use Thunderbird 68, as that uses the cleaned up code base and fixed lots of issues.

Another thing that came to my mind, migrating users to caldav and using the gdata APIs for anything missing also has the disadvantage of two permission prompts.

If TbSync is integrated into Thunderbird and it becomes the default way to add new accounts (of any kind), I think adapting the Provider for Google Calendar to use those new interfaces makes a lot of sense. I've also considered removing the code from comm-central and putting it into my github repo.

The Provider is in a unique position: while it is built with Lightning and has been in tree for ages, it isn't a shared project add-on like Lightning is. I'm happy to accept patches to change how account setup is done, but I'd like to keep ownership of the add-on.

If there are good reasons to externalize the Provider for Google Calendar now I'd love to hear, I could definitely move this to github if necessary.

If you put it on github, I could just try to turn it into a provider for TbSync and send you a PR for you to decide.

But what is really important for me, is that that Provider also does contacts (via Google API) with a single OAUTH2 permission prompt for everything. I have not done any research in that direction but I actually hope to get the author of gContactSync to join but would also do it myself, if that fails. What do you think?

This might require some renaming (...and Contacts) but I'm not opposed to that.

Great! Ping me, when the stuff is on github.

I think it is even possible to have something like sub repositories (I do not remember the correct term), so the contact sync stuff logic could even be in a different github repo (but linked to a subdirectories of your repo) and thus you would not need to open your repo for other contributors - in case you want to keep it closed.

Thanks for considering this!

Not sure how GProvider works with tasks to be sync'd with Google Calendar and also with calender apps following the standards (like Fruux, OwnCloud, Radicale, Baïkal).
From our dev with Reminderfox we only provided task sync with standard RFC because GCal has (had?) a very properity concept handling tasks. As Philipp said there are other issues with them like 'Important', or missing 'Categories', more?.
Moving/changing utilities to standards should be the top priority for any Thunderbird activity. For working with CalDav the sabre/dav is a good resource and the people behind it are very helpful! Worth to have a look for it.

Officially missing features seems to be listed here: https://developers.google.com/calendar/caldav/v2/guide.
I'm not too familiar with what what gdata supports unfortunately. I think it would be useful if we could list the differences.

From that source, it looks like the CalDAV implementation has not support for VTODO. That means no task support via CalDAV. Can someone confirm?

Yes that is known, and AFAIK the most significant omission.

I'm moving it to https://github.com/kewisch/gdata-provider , please bear with me while I'm transitioning all the issues and setup. Let's discuss specific actions then.

For the original request in this bug, I'm not excited to move users to CalDAV so I am closing this WONTFIX.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.