[dev] WebDAV/CalDAV integration - first questions

[Evert Pot]

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's also not very clear to me how GET requests are intercepted. How  
is this currently done?

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.

> 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