[dev] WebDAV package v0.1

[Jan Schneider]

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

> 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..

That sounds like a clean approach to me. OTOH we still need similar  
functionality for internal browsing, but it doesn't make sense to use  
objects extending Sabre_DAV classes for that purpose.
Does Sabre require those objects to extend the Sabre classes, or is it  
sufficient to implement a certain object API?

Jan.

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