Re: Exposing timeobjects to caldav
Ralf Lang <[email protected]> Fri, 4 Aug 2017 09:27:32 +0200
| Newsgroups | gmane.comp.horde.devel |
|---|---|
| Message-ID | <[email protected]> |
On 03.08.2017 15:58, Jan Schneider wrote: > > Zitat von Ralf Lang <[email protected]>: > >> Hallo, >> >> I wanted to expose a certain application's data (basically events) to >> caldav without removing kronolith nor nag. I am a little unsure which >> way to go, here is what I found: >> >> >> * Horde_Dav_Calendar_Backend scans the registry for apps providing the >> "calendar" and "tasks" interfaces. As each interface (at the root >> level) can only be exposed by one application, this limits the number >> of applications providing caldav calendars to two. >> >> * An application must expose $application::davGetCollections() to be >> able to provide arrays describing caldav folders >> >> * An application must expose $application::davGetObjects($collection) >> to be able to provide arrays describing caldav events or tasks >> >> * Kronolith does consume timeobjects providers as external calendars >> (listTimeObjects, listTimeObjectCategories) but does not expose them >> to caldav >> >> >> Solutions: >> >> * Make the application owner of the "tasks" api and pull nag's tasks , >> internally to this new interface. No change of horde upstream code >> needed, but very lame. > > Would be a nice workaround, but not a clean solution. > >> * Patching Kronolith is tempting, but I don't think it's wise to just >> expose random timeobjects providers to caldav interface without >> letting the admin or user decide. Kronolith is complicated and a prime >> horde app. > > I still think this is still the way to go. We should expose all calendar > backends to CalDAV, limiting their features where necessary, like > marking them read-only. Remote calendars might be an exception, since > they can be exposed directly to clients using the "subscriptions" CalDAV > extension. > If necessary, we could add a preference to allow users to only select a > number of calendar types (or even individual calendars) to be exposed > for synchronization. > Wow, that's quite some patch. I will consult with Diana if that is something we can easily provide within reasonable time. If this is the case, we will provide a PR. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: [email protected] B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- dev mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: [email protected]