[dev] WebDAV package v0.1

[Chuck Hagenbuch]

Quoting Evert Pot <evertpot at gmail.com>:

>>> Wouldn't a dependency be implied if anyone wants to use webdav  
>>> functionality? Unless you are talking about using the tree for  
>>> functionality beyond webdav..
>>
>> Yes, the latter.
>>
>>> If the reference in the _Application class is a concern, I'm  
>>> pretty sure everything will work correctly, unless the actual  
>>> 'getWebDavNode' or equivalent method would actually be executed.
>>>
>>> Can you help me understand the problem?
>>
>> We use the browse method not only for WebDAV access, but also  
>> internally, to browse from one application to objects of a  
>> different application. Since this feature resembles the same  
>> directory-like tree like we use in WebDAV/CalDAV, we should share  
>> the code. I don't stick to using a single browse() method, and I'm  
>> also fine with requiring Sabre for people that want CalDAV support,  
>> but whatever we chose for browsing the application resources should  
>> work without any dependency on external code. Hope this makes  
>> things clearer.
>
> It does make things clearer, however.. I don't think I'm up for the  
> task to build this api. If you are looking to build something that  
> provides tree-like access to the various horde components, well..  
> this is sort of out of the scope of what I'm trying to do.
>
> Would it be an option if I can just focus on the parts that are more  
> relevant to me? For me this would just be webdav and caldav protocol  
> support. The resulting code _should_ be simple, so if there are  
> future plans to map this to a unified backend, this should be doable.
>
> By no means I'm trying to quickly whip something up and offload it  
> for you guys to maintain, but I would like to stay within the scope  
> of creating a simple layer that connects SabreDAV to Horde's  
> controllers. I don't plan to make any changes in existing RPC  
> methods. It sounds like they are already in use for other purposes,  
> so perhaps this will even be an opportunity to remove some of the  
> webdavisms from that code, such as obscure properties that only make  
> sense for people with a fairly intimate knowledge of the  
> specifications.

I'm pretty sure Jan already responded here in the affirmative, but  
yes, that's fine. We can collaborate on the overall work that's  
necessary.

-chuck