[dev] Exposing timeobjects to caldav

[Ralf Lang]

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.

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

* Horde_Dav_Calendar_Backend could grab more applications from registry, 
either by hardcoding a downstream patch for an additional interface or 
by providing an upstream patch to run hasMethod('tobedefined') over all 
apps. This could be added as a feature patch to H5 and allow a 
bc-breaking removal of the hardcoded method in H6.

Why was the hardcoded limit to these two interfaces introduced? Is it a 
performance consideration?

Regards

Ralf

--
Ralf Lang
Linux Consultant / Develope
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