[dev] Exposing timeobjects to caldav

Ralf Lang lang at b1-systems.de
Fri Aug 4 07:27:32 UTC 2017


On 03.08.2017 15:58, Jan Schneider wrote:
> 
> Zitat von Ralf Lang <lang at b1-systems.de>:
> 
>> 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: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537


More information about the dev mailing list