Hardcoded collection name for CalDAV root

[yunosh]

It's theoretically possible to override the default collection name for the CalDAV root (CalDAV\Plugin::CALENDAR_ROOT) by overwriting the getName() method of CalDAV\CalendarRootNode. Unfortunately, CalDAV\Plugin::beforeGetProperties() doesn't use that method but hardcodes the calendar-home-set URI to use CALENDAR_ROOT.

[evert]

Hi!

Responding here to both this ticket, and #334, as they are strongly related.

I can change the CalDAV plugin to add a method like getCalendarRootForPrincipal . I'd still hardcode the means to construct the url, but this will allow you to override the way you determine the calendar root.

I like this much better than looping through a list of nodes to find various 'roots'. The 'root' is a sabredav concept, so it's better to allow you to specify full calendar-home-sets based on a principal url, for maximum flexiblity :)

I'd also keep the hardcoded getName() from the CalendarRootNode class (I think the default behaviour is a good one), but you can also easily override this by subclassing.

I can make sure this method can return 1 or more calendar-home-set paths per principal. However, I don't have much experience with multiple roots and I have a pretty strong hunch that clients will ignore anything past the first path. If compatibility is an important thing to you, I would try to abstract the various sources of calendar-data into a single calendar-home. I remember in the past you wanted to apply horde's application structure directly in the WebDAV tree, but my opinion is still that you're trying to put a round peg in a square hole ;)

[evert]

Regardless though, this will be a 1.9 feature :)

[yunosh]

I have given up on using the same tree in WebDAV and in CalDAV anyway, because you cannot combine both, at least with the current version of SabreDAV. The CalDAV plugin always overwrites the WebDAV structure if using the same root node. I still think it might make sense to have different calendar homes. You already have different DAV collections for CalDAV and CardDAV. If there is another application (like in Horde) that provides task lists, it should have a different calendar home than the calendar, to avoid potential ID collisions in the different trees, or confusing collection (calendar and task list) names.

[yunosh]

Nonetheless, I'm probably going down the road of combining all CalDAV providers into a single collection.

[evert]

It's the smart thing to do. Many clients will likely misbehave with more than 1 calendar-home.

In the simplest case you simply won't be able to create new calendars in more than 1 home (no interface to specify which it should be created in) and the worst case only 1 home is used and the rest is ignored.

Combining them may indeed not be as elegant, but it's the right thing to do for interoperability. You have a lot of flexibility in the id field that's used for individual calendars though. You can even use complex array structures with additional information on how to locate the correct calendar, and correct data provider.

[evert]

I don't really understand with the issue of combining WebDAV and CalDAV though.. That should just work unless I'm misunderstanding something.

The 'root node' can contain a number of sub-collections, and you should be able to add the calendar, contacts, principals node as well as anything else you want there.

[yunosh]

I tried if I could combine the existing WebDAV folders for calendars with the collections created by the CalDAV support. It would have made a more elegant folder tree, because now I have two different folders for WebDAV powered calendars and CalDAV powered calendars (three actually if I count tasks too). But that's just cosmetics.

[evert]

Ah gotcha.. you are talking about the feature to push iCalendar files, right? Considered adding a feature for that, all it would really take is to allow PUT on calendar collections and in the calendar-home, automatically overwriting any existing calendar that may be there.

Never really got into it because nobody really ever asked..

But if you wanted to support that, I'd do that by adding a plugin, more or less based on the following logic:

• intercept beforeMethod
• make sure it's a PUT
• make sure the parent folder for the PUT extends UserCalendars
• Check if the target calendar exists, if so: delete it
• Parse the object using the VObject\Splitter objects and re-create each event.

Hope this helps

[yunosh]

Well, we already have that implemented on the API level of Horde, so I'm fine with using the existing WebDAV API of Sabre to tie those ends together.

[evert]

Alright, makes sense :)

[yunosh]

Your suggestion to use the collection's ID field to match objects back into the correct calendar/task list/application doesn't work well though. At least not if you allow the clients to create collections. For our special use case, collections can only handle either tasks or events, while the clients don't know that when creating collections. Beside that, we must use the ID provided by the client, so we can no longer rely on the ID carrying the target application of some sorts. Resolving this issue involves a bunch of intransparent magic by checking the ID format and looking up a table for IDs created externally. But if that's what we have to do to most compatibly support clients, so be it.

[evert]

One option (although perhaps a bit crazy) is to create both a tasklist and a calendar when this is requested, and merge the result. I'm not sure how I solved this for Sapo. I have a feeling it made more sense at the time to not allow creation of new calendars/tasklists but I could very well be wrong there.

At least the case where clients create just the VTODO or the VEVENT calendar is easier, and at least all new apple clients do just this.

[evert]

Will be released as 1.9.0.