CalDav against Google: "Missing capabilities: Couldn't determine principal path (RFC 5397)"
-
Thanks for debugging!
I don’t use the Google Calendar app because I’m running Replicant on my Samsung S3 and want as little proprietary stuff on my phone as possible. As far as I can tell, you can’t use Google Calendar without also installing some non-free stuff (like GAPPS).
-
Ok… so I suggest to use a free calendar server, too
Or if you have to rely on Google calendar for some reasons, you will have to use GApps, too.
-
Hi, I personaly have to use the google calendar server because of the company I’m working for.
However I want to keep my phone ‘gapps’ free.
Acal is working perfectly as a google calendar client but I would prefer using davdroid. Why? because that would allow me to use the default calendar (much more nicer interface than acal).
-
@jeekajoo I understand. However at the moment it’s not possible because Google lacks support for RFC 5397.
-
Reflecting on this, I wonder how aCal deals with Google Calendar? Obviously aCal works against Google. Presumably aCal doesn’t need or require this particular aspect of CalDAV to work. Maybe there is a workaround in aCal to get the same functionality some other way? I’m wondering if maybe DAVDroid could be adapted to either use a similar workaround, or be adapted to work even though this particular feature is not supported by the server.
Speaking as a old IMAP implementer, I fully understand the ugliness of adding code to support broken servers (there are many broken IMAP servers around), and one should be hesitant about adding such code, but sometimes workarounds can be fairly small and not pose significant risks of breaking something else. I guess the same applies to the CalDAV protocol and implementations therof. Perhaps we can discuss possible workarounds in this bug report.
I suggest the next step (for anyone interested) to move forward on this is to 1) figure out how aCal works around this, and/or 2) debug how the Google CalDAV server work and try to come up with a workaround. Until there is more knowledge here, I don’t think we can write a patch, and without a patch I don’t think we’ll see any progress here.
/Simon
-
Reflecting on this, I wonder how aCal deals with Google Calendar? Obviously aCal works against Google. Presumably aCal doesn’t need or require this particular aspect of CalDAV to work. Maybe there is a workaround in aCal to get the same functionality some other way? I’m wondering if maybe DAVDroid could be adapted to either use a similar workaround, or be adapted to work even though this particular feature is not supported by the server.
Current Principal isn’t even a part of CalDAV but an additional extension that allows auto-detection of CalDAV/CardDAV collections. So Google isn’t required to support this in any way to be standards-compliant. However, we have decided to require auto-detection as most servers support it and without it, the setup process would be much more complicated and error-prone.
Speaking as a old IMAP implementer, I fully understand the ugliness of adding code to support broken servers (there are many broken IMAP servers around), and one should be hesitant about adding such code, but sometimes workarounds can be fairly small and not pose significant risks of breaking something else. I guess the same applies to the CalDAV protocol and implementations therof. Perhaps we can discuss possible workarounds in this bug report.
Two things:
- We have founded DAVdroid as a way to escape Google (meaning Google address book and Google Calendar) and still use our Android devices. This was our personal motivation, so we don’t like to support Google Calendar in any way. If it would work like any other CalDAV/CardDAV service, there wouldn’t be any reason to not use it with DAVdroid, but I won’t do any work just to support Google services (which I want to get rid of). I understand that Google support might by useful for some users, but my disfavor is a personal thing. Pull requests are, however, appreciated.
- We don’t do server-specific workarounds: We give our best to improve the standards-compliance of DAVdroid. If we discover that some server/service is not compliant, we will report these problems to the manufacturer and help them to make it compliant. So servers and clients are improved. (Note: We just discovered a service that had a User-Agent based decision algorithm that served corrupted data only to DAVdroid because they had implemented a work-around for a DAVdroid bug that has been fixed long ago.) Again, this might not be the short-time optimum for users, but over a long time they will benefit from improved servers and clients, making the whole CalDAV/CardDAV experience smoother. I’m happy that we don’t have an economic dependency of DAVdroid, so we can afford to push our own way.
I suggest the next step (for anyone interested) to move forward on this is to 1) figure out how aCal works around this, and/or 2) debug how the Google CalDAV server work and try to come up with a workaround. Until there is more knowledge here, I don’t think we can write a patch, and without a patch I don’t think we’ll see any progress here.
As said above, I’m not actively interested in working Google support. However, if someone can contribute a good and standards-compliant solution that allows DAVdroid to be used with Google, we’d of course merge the changes.
-
Can this please be reopened?
I do not want to use Google Calendar directly because that requires me to add the Google Account from my employer to my device. That requires me to accept my employer as a remote device administrator. I am frankly not interested in that and wanted to use this app as a work-around.
-
@rfc2822 Could you please write in your http://davdroid.bitfire.at/what-is-davdroid that your app does not sync google calendar. Will save time for others. Thanks.
-
If you wan’t to use native Android account management instead of aCal, use https://f-droid.org/repository/browse/?fdid=org.gege.caldavsyncadapter, work great with my entreprise account https://github.com/gggard/AndroidCaldavSyncAdapater/wiki/Server-Compatibility-List with the version 1.8 not the 1.8.1
-
Whoo , just read the comments on this bug and I’m a bit surprised.
If google did not support the required bits of DAV protocol, I would understand but you are saying something like " we don’t want to put some manual way of feeding the DAV urls to the apps because autodiscovery is great and we hate google".I understand it’s a lot of work, but it would make common people able to use android without gapps.
-
" we don’t want to put some manual way of feeding the DAV urls to the apps because autodiscovery is great"
Correct.
“and we hate google”.
Speaking for me personally, correct (although my opinion is a bit more differentiated). But that’s not the point in this issue. The point is that I
- don’t want to do work just to get Google Calendar running
- while there is already a working (and better working!) Google Calendar app, namely Google Calendar. If you really need Google, well then install GApps. Why not?
But of course, if someone submits a high-quality pull request that has a well-done UI that doesn’t interfere with auto-detection and doesn’t cause any other problems, I’ll be happy to merge it. We won’t lock out Google Calendar specifically for any reason, but we won’t do any extra work just to get it working, too, especially because there’s a working Google Calendar app.
-
@freechelmi I think you got the order of things mixed up. It is Google that cares little about extensive CalDAV support. Otherwise, Google would have implemented auto-detection already, or at least they’d have plans to do so in the near future. After all, there are plenty of talented and funded software developers working there. It only makes sense that Google should be working to make its own products more accessible to third party developers and end users, not the other way around. After all, they’re the company making money here. (Although because they have their own functional calender application – regrettably part of a bundle that many of us find distasteful – it’s unlikely their priorities will shift.)
-
@dper Totally agree with you as well, I think Card/Caldav is also important to google, as it’s the official way for iOs and windowsphone to sync AFAIK.
-
Please follow up in #234.
