[dev] WebDAV package v0.1

[Evert Pot]

Sorry for the late responses, I was on a trip for a week with very  
little internet access.

>> I want to add a dedicated Web/SabreDAV interface to Kronolith,  
>> replacing the existing methods from the RPC system. One suggestion  
>> is to add a new method to to Kronolith_API, called something like  
>> getWebDAVTree, or add a new file called Kronolith_DAV, which is  
>> automatically discovered(not sure how that would work within horde??)
>
> What do you mean by replacing the existing methods? The existing  
> webdav code? Or the API methods themselves?
>
> We have autoloading; what would Kronolith_DAV need to be discovered  
> by? I guess I'm not following the overall shape of your suggestion.

This is a brief overview of how the webdav system works right now:

The top level directory is a listing of all horde applications. Only  
horde applications that have the 'browse' rpc method are added to this  
list.
This RPC class has a number of methods, such as get, put, path_delete  
and mkcol that all take a path argument, and internally handle the API  
method based on the path.

All these methods in every API class (Kronolith_Api, Nag_Api, etc..)  
will have to maintain some sort of translation of this path to an  
internal controller. The datasource of a 'browse' on a list of users,  
will have to originate from a very different subsystem than for  
example a list of calendar objects, or directory tree in Gollem.


How SabreDAV was designed is very different, it could definitely be  
argued there are cons to this approach, but I do feel it helps keeping  
things simpler.
Simply put SabreDAV has three node classes:

Node
File (extends Node)
Directory (extends Node)

The File class adds methods such as 'get' and 'put, and the Directory  
class adds methods such as 'getChildren' and 'createFile'.
The biggest difference is that there is no central API class that  
handles all HTTP methods for various paths, but every single file or  
directory is represented by 1 object.

The implication is that the Dav api's for every Horde application will  
likely consist of a couple of classes, every class representing a  
different type of object within horde (1 for a file in gollem, 1 for a  
directory in gollem, 1 for a list of kronolith users, and so on..).  
This will result in more classes, but smaller chunks of simple  
functionality.

One way to approach this, is for example a class such as this:

class Kronolith_Dav {

   function getRootNode() {

     return new Kronolith_Dav_UserList();

   }

}

Here are some stubs of classes that would appear within Kronolith:

class Kronolith_Dav_UserList extends Sabre_DAV_Directory {

   function getChildren() {

     // logic for listing all the users

   }

   function getChild($name) {

     // logic for returning a single users' object.

   }

   function getName() {

     // the path name that will be used in the webdav directory  
structure.
     return 'kronolith';

   }

}

class Kronolith_Dav_User extends Sabre_DAV_Directory {

   function getChildren() {

     // logic for listing all a users calendars

   }

   function getName() {

     // This is probably a username
     return 'chuck';

   }

   function createCalendar($name) {

     // Creates a new calendar with the supplied filename.

   }

}

And another one:

class Kronolith_Dav_CalendarObject extends Sabre_DAV_File {

   function get() {

      // returns the current iCalendar object

   }

   function put() {

      // updates the current iCalendar object

   }

}

Does this make sense at all? I'm not sure if I'm explaining this well..

Evert