[dev] WebDAV/CalDAV integration - first questions

[Jan Schneider]

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.

> =Relation to WebDAV=
>
> I also heard there was a desire to also use SabreDAV as the standard  
> library for the existing WebDAV implementation.
> I'm happy to provide this, and perhaps I should even start off with  
> this; so I can get more familiar with the horde codebase.
>
> Any opinions about this?

Since this was my idea, I'm obviously biased, but I still like the idea.

> I will be able to either provide a different endpoint for WebDAV, e.g.:
>
> /horde/rpc.php/webdav
> /horde/webdav.php
>
> Or I can combine both the WebDAV and CalDAV directory structure. The  
> latter might be a bit slower, due to the extra hook-ins the  
> CalDAV-related plugins have.

I prefer the latter. There is no use in keeping two different  
endpoints or libraries IMO.

> =Authentication=
>
> Most clients seem to prefer HTTP Digest over HTTP Basic. Although  
> HTTP Basic auth is support by virtually any client, many will give  
> warnings if it's not used in combination with SSL.
> I've noticed Horde uses Basic everywhere.
>
> If you guys want to use Digest, some changes will have to be made in  
> the authentication system to store an extra hash.
>
> Opinions?

Horde supports a huge variety of authentication backend, so this could  
only be an optional addition for backends that are completely under  
our control. This actually reduces the capable backends to SQL, and  
maybe LDAP if we introduce an optional custom attribute.
Most people use backends that don't provide clear text passwords or  
allow to store arbitrary data for users.

So it boils down to: it's nice to have but won't work with most  
installations anyway. It makes sense for the SQL authentication  
backend, but priority should be low.

> =CalDAV virtual directory structure=
>
> I just wanted to bring this topic up once more. Some ideas have been  
> brought forward by Jan on how to build up the CalDAV directory  
> structure.
> One of these ideas was to separate the virtual directories for Nag  
> and Kronolith.
>
> I'm against this.. Users will generally never be aware of these  
> directory structures as they are obfuscated with long uuids. In  
> order to keep things reasonably simple, I will need  to start off  
> with something like :
>
> caldavroot/users/Administrator/calendars/UUID/UUID
>
> Perhaps down the road there will be the possibility to juggle a  
> little bit with these pathnames, but in the short term I kinda need  
> some flexibility.
> I'm just mentioning this so there is no confusion around how this is  
> going to work.

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.

Jan.

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