[PoC] Allow apps to add their own collection to the calendar-home-set

[juliusknorr]

This way apps providing a CalDAV collection can be found by clients
looking for the calendar-home-set. Since some client implementations
only check for the first entry in that set, we need to make sure that
the calendars collection is at index 0.

This is as it is specified in RFC 4791 https://tools.ietf.org/html/rfc4791#section-6.2.1

Use case

With #6835 apps can register custom dav collections. For the https://github.com/nextcloud/deck I plan to implement an additional CalDAV endpoint, that exposes each board as a calendar. In order to let apps like davdroid detect existing calendars using the calendar-home-set, it should be possible for apps to extend this.

Client implementations

Clients that can handle multiple entries:

• davdroid
• Outlook CalDAV synchronizer Bad url construction when multiples calendar-home-set. aluxnimm/outlookcaldavsynchronizer#139

Clients that use only the first entry:

• Nextcloud calendar app
• Nextcloud tasks app
• Evolution
• gnome-online-accounts (gnome-calendar/gnome-todo)
• macOS
• iOS (untested)

Clients that break:

• Fantastical

I'm not sure if there are clients that will have problems with this implementation, but in general they should be fine, since the first entry will always be the Nextcloud default calendar set.

cc @nextcloud/calendar @nextcloud/tasks

[juliusknorr]

cc @nickvergessen @georgehrke @schiessle as you recently commited to the dav app. 😉

[georgehrke]

I really like the idea of enabling apps to register their own calendars. I was looking forward to develop some GitHub Calendar app for a long time, that would automatically create VTODOs for your assigned issues and show VEVENTs for milestones of repositories that you are a collaborator of.

But to be honest I'm not very sure about this approach. Do you have a PoC in the deck app that already integrates this? You only talked about DavDroid and Evolution so far. I would like to know if there are issues with clients like the Outlook caldav sync connector, iOS, macOS and Fantastical.
If all those clients don't support multiple calendar-home-sets, it would be quite a bummer.

Furthermore I see issues with not being able to share, publish (and most likely not being able to delete) such calendars. All the sharing / publishing logic would have to be reimplemented by each calendar-home.

[codecov]

Codecov Report

Merging #6995 into master will decrease coverage by <.01%.
The diff coverage is 28.57%.

@@             Coverage Diff              @@
##             master    #6995      +/-   ##
============================================
- Coverage     52.82%   52.81%   -0.01%     
- Complexity    22817    22831      +14     
============================================
  Files          1443     1443              
  Lines         88589    88608      +19     
  Branches       1349     1349              
============================================
+ Hits          46795    46799       +4     
- Misses        41794    41809      +15

Impacted Files	Coverage Δ	Complexity Δ
apps/dav/lib/Server.php	46.62% <100%> (+0.36%)	17 <0> (ø)	⬇️
apps/dav/lib/CalDAV/Plugin.php	34.78% <25%> (-65.22%)	16 <16> (+14)

[juliusknorr]

But to be honest I'm not very sure about this approach. Do you have a PoC in the deck app that already integrates this?

I have a messy local branch, that by now works just read-only. I can clean that up and push it tomorrow, so you can have a look. It is basically a custom CalDavBackend and CalendarRoot implementation.

You only talked about DavDroid and Evolution so far. I would like to know if there are issues with clients like the Outlook caldav sync connector, iOS, macOS and Fantastical.

Those were the ones I have around. I don't have any iOS/MacOS device at the moment. But yes, i only davdroid is able to use multiple homes, then we should consider something different.

Furthermore I see issues with not being able to share, publish (and most likely not being able to delete) such calendars. All the sharing / publishing logic would have to be reimplemented by each calendar-home.

Another option might be to add some API that allows apps to extend the nextcloud calendars (either by injecting events or adding own calendars). I only started working on this PoC for now, since it seemed to be the simplest solution without interfering with the existing dav system to much.

[georgehrke]

I can clean that up and push it tomorrow, so you can have a look

That would be great! I would be happy to test it with iOS/macOS/Fantastical

Another option might be to add some API that allows apps to extend the nextcloud calendars (either by injecting events or adding own calendars). I only started working on this PoC for now, since it seemed to be the simplest solution without interfering with the existing dav system to much.

I'm really torn between those two concepts.
Pros:
✅ not interfering with the existing dav system too much
✅ clear distinct separation of user calendars and app-generated calendars

Cons:
❌ no sharing / publishing out of the box
❌ deletion has to be managed by corresponding apps (that's probably true for other approaches too)
❌ client-support not perfect (not our fault, as it complies with CalDAV standard)

Maybe the dav-app could allow calendar-homes to register their own sharing-types (like deck-calendar in this case), so that other calendar-homes could rely on the already existing calendar-sharing and calendar-publishing code.

[juliusknorr]

@georgehrke Here we go: https://github.com/nextcloud/deck/compare/dav

Outlook CalDAV Synchronizer seems to support multiple calendar homes: aluxnimm/outlookcaldavsynchronizer#139

[georgehrke]

@juliushaertl You will be at the hackweek right?

I checked out the deck branch, forced it to upgrade the appconfig, created a board and a card with a deadline, but yet I only see one calendar-home.

[tcitworld]

My opinion on clients not knowing other calendar-home-set is that it doesn't matter much as long as each calendar in other calendar-home-set can be added manually with it's own CalDAV URL.
Lightning on Thunderbird doesn't even know how to handle the current one...

[juliusknorr]

@georgehrke Yes, I'll be there on thursday. I just pushed a fix for this. It seems that when only requesting a single property, it somehow loaded the parent CalDAV plugin first.

@tcitworld Yep good point, but we need to be sure that this doesn't break any existing caldav client.

[georgehrke]

macOS only shows the first calendar-home-set
Didn't test iOS but I'm pretty sure the behavior is the same

Fantastical keeps crashing ever since I added the endpoint with multiple calendar homes ...

Edit: I reported this bug to Fantastical and they have provided me with a patch, which I have yet to test.

[juliusknorr]

@georgehrke Great, thanks for testing and also reaching out to fantastical. I've updated the list in the first post with that information.

Maybe the dav-app could allow calendar-homes to register their own sharing-types (like deck-calendar in this case), so that other calendar-homes could rely on the already existing calendar-sharing and calendar-publishing code.

I'll need to have a more detailed look on the calendar sharing code to see if there might be an easy way to avoid each app building their own code there.

[georgehrke]

Given how many calendars only show the first calendar home, we might want to consider different approaches. What do you think?

[juliusknorr]

@georgehrke Yes, actually makes sense to invest time into a different approach. Custom caldav endpoints can be implemented already, so adding the calendar to the home set is quite a small enhancement. Let's close this. I'll open a issue so we can discuss other implementation ideas.

[georgehrke]

@juliushaertl What do you think about this alternative approach:

• Allow apps to register calendars inside the principals/system/system principal uri.
• This way they are accessible by no one by default.
• In order to make them accessible, selectively share them with the users they are meant for.

(Or have principals/system/deck-app / principals/system/github-milestone-app)