[dev] WebDAV package v0.1

[Chuck Hagenbuch]

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

[snip]

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

Yes, this sounds good and I agree with the general approach. I  
wouldn't take the current Horde API classes as gospel too much -  
they're to a pretty old API at this point, and if I were to do it over  
again I'd split things up a lot more. This is an opportunity to do  
that, at least in part.

-chuck