[dev] WebDAV/CalDAV integration - first questions

[Jan Schneider]

Zitat von Evert Pot <evertpot at gmail.com>:

>
> On 2009-09-23, at 12:18 PM, Jan Schneider wrote:
>
>> Zitat von Evert Pot <evertpot at gmail.com>:
>>
>>> Hey guys,
>>>
>>> =Base url=
>>>
>>> I was told the best place to integrate CalDAV, was through rpc.php.
>>>
>>> Looking at that file, it appears it is almost completely based on  
>>> autodetection.
>>> I think it's preferable to have a dedicated url for CalDAV support.
>>>
>>> I can either make the base url something like:
>>>
>>> /horde/rpc.php/caldav/
>>>
>>> or:
>>>
>>> /horde/caldav.php/
>>>
>>> Any preferences?
>>
>> Why? WebDAV detection works fine, and if CalDAV is going to replace  
>> WebDAV, I see no reason why this shouldn't keep working.
>
> Largly its a downright aversion against magic behaviour. In this  
> case specifically, I'm worried about certain requests triggering one  
> of the other RPC's.

It worked fine for the last few years, and I don't see why it should  
stop working. If it breaks at some point, we can always change it later.

> It's also not very clear to me how GET requests are intercepted. How  
> is this currently done?

By detecting PATH_INFO requests.

> Lastly, the entire response appears to be buffered and sent as a  
> string from the default rpc.php. I'd like to avoid this and use php  
> streams instead. This can be a big memory saver. I've been able to  
> up/download up to 2GB files without triggering a memory_limit  
> setting of 64MB.

That's nice to have, but not a show stopper. Beside that, everything  
can be changed for H4 as needed. So if using streams is really an  
important concern for you, you can change Horde_Rpc to support them.  
We already did this for some other libraries where it made sense.

>> I'm not sure if this will work, because tasks and calendars are  
>> indeed provided by completely different applications. We might  
>> allow Kronolith to proxy CalDAV task access to Nag though.
>>
>> For the directory structure, I still prefer to keep BC with the  
>> current structure we have that would be:
>> kronolith/username/calendarid/eventid
>>
>> If you don't want this to be the default structure for SabreDAV,  
>> then we need some hook/plugin to provide a different structure with  
>> our backend.
>
> From the SabreDAV library there is some flexibility to setup  
> different structures. Just for my own sanity I will start off with a  
> structure that is the easiest to understand. Based on what I learned  
> at that point, we can look at this again.
>
> My point of view is that there is no need for applications  
> (kronolith, nag) to inject new paths in CalDAV structure, instead  
> they could just register themselves as a new CalDAV-enabled backend.  
> I plan to hide as much of the protocol as possible from the  
> backends, if we need support for multiple collections of calendars  
> per user (which is what this is really about) it could imply that  
> the various backends need to be much more aware of the structure as  
> needed; which is something I'd like to avoid.
>
> Regardless I will start off simple, and just with kronolith. Once  
> we're there it will be easier for me to figure out how multiple  
> directory structures work, or articulate why it will be  
> inconvenient. Just keep an open mind, and so will I =)
>
> Evert
>
>



Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/