[dev] Exposing timeobjects to caldav

[Ralf Lang]

On 13.08.2017 11:51, Ralf Lang wrote:
> 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.
> 
As external events pop up out of nowhere, there is no internal or 
external object id. For collections, getExternalCollectionId 
automagically calls addCollectionMap if missing. 
Horde_Dav_Storage::getExternalObjectId however doesn't implicitly add 
object maps. This is inconsistent, but can be worked around by checking 
for an exception in Application::davGetObjects


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