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.
- 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.