[dev] Exposing timeobjects to caldav

[Ralf Lang]

On 04.08.2017 09:27, Ralf Lang wrote:
> 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.

I've been looking at this.
For now, all externals will be presented readonly.

I the visible name of the external collection contains the provider name 
and the collection name. For instance, if the provider was whups 
(declared as "Tickets" in the horde menu) and the collection label was 
"My Tickets by Due Date", this would be "Tickets - My Tickets by Due Date".

I tried to sort the external calendars into a subfolder but this proved 
tricky without patching Horde_Dav, which is out of scope for a kronolith 
patch. For now, I stick with a flat user/calendars hierarchy, only 
visibly discerning shares from externals.

Under the application name path (like whups), it seems Horde_Dav just 
invokes browse() to return a tree level. I am not sure but this looks 
like plain webdav instead of caldav.

I think I am on the right track now. It's all settling step by step.

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