Re: Exposing timeobjects to caldav

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.

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

It was a natural choice, and it didn't require us to instantiate every  
application object.

For the future we should use interfaces and reflections to detect the  
capabilities that an application provides.


-- 
Jan Schneider
The Horde Project
https://www.horde.org/

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]